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

Протокол Lightweight Directory Access ( LDAP / ɛ л d æ р / ) является открытым, продавец-нейтральный, промышленный стандарт протокол прикладного доступа и поддержания распределенных информационных каталогов услуг над Internet Protocol сети (IP). ^[1] Службы каталогов играют важную роль в разработке приложений интрасети и Интернета, позволяя обмениваться информацией о пользователях, системах, сетях, услугах и приложениях по всей сети. ^[2] Например, службы каталогов могут предоставлять любой организованный набор записей, часто с иерархической структурой, например корпоративный каталог электронной почты . Точно так же телефонный справочник - это список абонентов с адресом и номером телефона.

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

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

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

История [ править ]

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

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

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

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

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

Обзор протокола [ править ]

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

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

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

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

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

Структура каталогов [ править ]

Протокол предоставляет интерфейс с каталогами, которые соответствуют версии 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 сп: Джон Доу givenName: Джон sn: Доу Телефон: +1888555 6789 Телефон: +1888555 1232 почта: [email protected] менеджер: cn = Barbara Doe, dc = example, dc = com objectClass: inetOrgPerson objectClass: organizationPerson objectClass: человек objectClass: сверху

" 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 вставляет новую запись в базу данных сервера каталогов. ^[11] Если отличительное имя в запросе на добавление уже существует в каталоге, то сервер не будет добавлять повторяющуюся запись, а установит код результата в результате добавления как десятичный 68, «entryAlreadyExists». ^[12]

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

dn: uid = user, ou = people, dc = example, dc = comchangetype: добавитьobjectClass: сверхуobjectClass: человекuid: пользовательsn: фамилияcn: common-nameuserPassword: пароль

В приведенном выше примере 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 (Simple Authentication and Security Layer) BIND предоставляет услуги аутентификации с помощью широкого набора механизмов, например Kerberos или сертификата клиента, отправленного с TLS. ^[13]

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

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

Удалить [ редактировать ]

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

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

Искать и сравнивать [ редактировать ]

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

baseObject

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

объем

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

фильтр

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

derefAliases

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

атрибуты

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

sizeLimit, timeLimit

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

typesOnly

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

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

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

Изменить [ изменить ]

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

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

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

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

dn: dc = пример, dc = comchangetype: изменитьдобавить: cncn: the-new-cn-value-to-be-добавлено-

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

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

Существует также расширение Modify-Increment ^[17], которое позволяет увеличивать значение атрибута на определенную величину. В следующем примере с использованием LDIF значение employeeNumber увеличивается на 5 :

dn: uid = user.0, ou = people, dc = example, dc = comchangetype: изменитьприращение: employeeNumberemployeeNumber: 5-

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

Изменить DN [ править ]

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

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

Расширенные операции [ править ]

Расширенная операция - это общая операция 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 только шифруют обмен данными; они не сверяют имя хоста с именем в предоставленном сертификате. ^[20]

Отказаться [ править ]

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

Отменить привязку [ править ]

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

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

Схема URI [ править ]

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

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

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

• host - это полное доменное имя или IP-адрес сервера LDAP для поиска.
• порт - сетевой порт ( порт по умолчанию 389) сервера LDAP.
• DN - это отличительное имя для использования в качестве базы поиска.
• Атрибуты - это список извлекаемых атрибутов, разделенных запятыми.
• scope определяет область поиска и может быть "базовой" (по умолчанию), "одной" или "дополнительной".
• filter - это поисковый фильтр. Например, (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. ( Операционный атрибут описывает работу каталога, а не информацию о пользователе, и возвращается из поиска только тогда, когда он явно запрошен.)

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

Варианты [ править ]

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

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

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

Другие модели данных [ править ]

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

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

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

Использование [ править ]

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

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

Как в X.500 [2008], так и в LDAPv3 используются в основном два общих стиля именования. Они задокументированы в спецификациях ITU и RFC IETF. Исходная форма занимает верхний объект уровня в качестве объекта страны, таких как 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 . O'Reilly Media . ISBN 978-1-56592-491-8.
• Донли, К. (2002). Программирование, управление и интеграция LDAP . Публикации Мэннинга . ISBN 978-1-930110-40-3.
• Howes, T; Смит, М; Хорошо, G (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 .