Облегченный протокол доступа к каталогу ( LDAP / ˈ ɛ l d æ p / ) — это открытый, независимый от поставщика стандартный протокол приложений для доступа и поддержки распределенных информационных служб каталогов по сети Интернет-протокола (IP). [1] Службы каталогов играют важную роль в разработке приложений для интрасети и Интернета, позволяя обмениваться информацией о пользователях, системах, сетях, службах и приложениях по всей сети. [2] Например, службы каталогов могут предоставлять любой организованный набор записей, часто с иерархической структурой, например корпоративный каталог электронной почты . Точно так же телефонный справочник представляет собой список абонентов с адресом и номером телефона.
LDAP указан в серии публикаций стандартной версии Инженерной группы Интернета (IETF) под названием Request for Comments (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 . Эта модель доступа к каталогу была заимствована из протоколов DIXIE и Directory Assistance Service .
Протокол был первоначально создан [7] Тимом Хоузом из Мичиганского университета , Стивом Киллом из Isode Limited, Колином Роббинсом из Nexor и Венджиком Йонгом из Performance Systems International , примерно в 1993 году, как преемник [8] DIXIE и 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, см. ниже). [9] Затем клиент отправляет запрос операции на сервер, а сервер отправляет в ответ ответы. За некоторыми исключениями, клиенту не нужно ждать ответа перед отправкой следующего запроса, и сервер может отправлять ответы в любом порядке. Вся информация передается с использованием базовых правил кодирования (BER).
Клиент может запросить следующие операции:
Кроме того, сервер может отправлять «незапрошенные уведомления», которые не являются ответами на какой-либо запрос, например, до истечения времени ожидания соединения.
Распространенным альтернативным методом защиты связи LDAP является использование туннеля SSL . Порт по умолчанию для LDAP через SSL — 636. Использование LDAP через SSL было обычным явлением в LDAP версии 2 (LDAPv2), но оно никогда не было стандартизировано ни в одной формальной спецификации. Это использование устарело вместе с LDAPv2, который был официально прекращен в 2003 году. [10]
Протокол обеспечивает интерфейс с каталогами, которые соответствуют модели X.500 издания 1993 года :
/foo/bar/myfile.txtбыло DN, то это myfile.txtбыло бы RDN).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" для фамилии. [11]
Сервер хранит поддерево, начинающееся с определенной записи, например " dc=example,dc=com" и ее дочерних элементов. Серверы также могут содержать ссылки на другие серверы, поэтому попытка доступа к " ou=department,dc=example,dc=com" может вернуть ссылку или ссылку продолжения на сервер, который содержит эту часть дерева каталогов. Затем клиент может связаться с другим сервером. Некоторые серверы также поддерживают цепочку , что означает, что сервер связывается с другим сервером и возвращает результаты клиенту.
LDAP редко определяет какой-либо порядок: сервер может возвращать значения атрибута, атрибуты в записи и записи, найденные в результате операции поиска, в любом порядке. Это следует из формальных определений – запись определяется как набор атрибутов, а атрибут – это набор значений, и наборы не обязательно упорядочивать.
Операция ADD вставляет новую запись в базу данных сервера каталогов. [12] Если отличительное имя в запросе на добавление уже существует в каталоге, сервер не добавит повторяющуюся запись, а установит код результата в результате добавления как десятичное 68, «entryAlreadyExists». [13]
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. [14]
BIND также устанавливает версию протокола LDAP, отправляя номер версии в виде целого числа. Если клиент запрашивает версию, которую сервер не поддерживает, сервер должен установить код результата в ответе BIND на код ошибки протокола. Обычно клиенты должны использовать LDAPv3, который используется по умолчанию в протоколе, но не всегда в библиотеках LDAP.
BIND должна была быть первой операцией сеанса в LDAPv2, но в LDAPv3 она не требуется. В LDAPv3 каждый успешный запрос BIND меняет состояние аутентификации сеанса, а каждый неудачный запрос BIND сбрасывает состояние аутентификации сеанса.
Чтобы удалить запись, клиент LDAP передает на сервер правильно сформированный запрос на удаление. [15]
hasSubordinates, значение которого указывает, имеет ли запись какие-либо подчиненные записи, а некоторые серверы поддерживают операционный атрибут numSubordinates[16] , указывающий количество записей, подчиненных записи, содержащей этот numSubordinatesатрибут.Операция поиска используется как для поиска, так и для чтения записей. Его параметры:
BaseObject(поиск только по именованной записи, обычно используется для чтения одной записи), singleLevel(записи непосредственно под базовым DN) или wholeSubtree(все поддерево, начиная с базового DN).(&(objectClass=person)(|(givenName=John)(mail=john*)))выберет «лиц» (элементы objectClass person), для которых заданы правила соответствия, givenNameи mailопределит, соответствуют ли значения этих атрибутов утверждению фильтра. Обратите внимание, что распространенным заблуждением является то, что данные LDAP чувствительны к регистру, тогда как на самом деле правила сопоставления и правила упорядочивания определяют сопоставление, сравнения и отношения относительных значений. Если фильтры примера должны были соответствовать регистру значения атрибута, необходимо использовать расширяемый фильтр соответствия , например:(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))Сервер возвращает соответствующие записи и, возможно, ссылки на продолжение. Их можно вернуть в любом порядке. Конечный результат будет включать код результата.
Операция сравнения принимает DN, имя атрибута и значение атрибута и проверяет, содержит ли именованная запись этот атрибут с таким значением.
Операция MODIFY используется клиентами LDAP для запроса того, чтобы сервер LDAP внес изменения в существующие записи. [17] Попытки изменить несуществующие записи завершатся неудачей. Запросы MODIFY подлежат контролю доступа, реализованному сервером.
Для операции MODIFY необходимо указать различающееся имя (DN) записи и последовательность изменений. Каждое изменение в последовательности должно быть одним из:
Пример LDIF добавления значения к атрибуту:
dn : dc = example , dc = com тип изменения : изменить добавить : cn cn : новое-значение-cn, которое будет добавлено - Чтобы заменить значение существующего атрибута, используйте replaceключевое слово. Если атрибут является многозначным, клиент должен указать значение атрибута для обновления.
Чтобы удалить атрибут из записи, используйте ключевое слово deleteи указатель типа изменения modify. Если атрибут является многозначным, клиент должен указать значение удаляемого атрибута.
Существует также расширение Modify-Increment [18] , которое позволяет увеличивать значение инкрементируемого атрибута на указанную величину. В следующем примере используется увеличение LDIF employeeNumberна 5:
dn : uid = user.0 , ou = люди , dc = example , dc = com тип изменения : изменение приращения : номер сотрудника номер сотрудника : 5 - Когда серверы LDAP находятся в реплицируемой топологии, клиентам LDAP следует рассмотреть возможность использования контроля после чтения для проверки обновлений вместо поиска после обновления. [19] Контроль после чтения разработан таким образом, что приложениям не нужно выдавать запрос на поиск после обновления — это плохой тон — получать запись с единственной целью проверки того, что обновление сработало, из-за модели конечной согласованности репликации . Клиент LDAP не должен предполагать, что он подключается к одному и тому же серверу каталогов для каждого запроса, поскольку архитекторы могли разместить балансировщики нагрузки или прокси-серверы LDAP, или и то, и другое между клиентами и серверами LDAP.
Изменение DN (перемещение/переименование записи) принимает новое RDN (относительное отличительное имя), при необходимости DN нового родительского элемента, а также флаг, указывающий, следует ли удалять значения в записи, соответствующие старому RDN. Сервер может поддерживать переименование целых поддеревьев каталога.
Операция обновления является атомарной: другие операции увидят либо новую запись, либо старую. С другой стороны, LDAP не определяет транзакции, состоящие из нескольких операций: если вы прочитали запись, а затем изменили ее, другой клиент мог тем временем обновить запись. Однако серверы могут реализовывать расширения [20] , поддерживающие это.
Расширенная операция — это общая операция LDAP, которая может определять новые операции, которые не были частью исходной спецификации протокола. StartTLS — одно из наиболее важных расширений. Другие примеры включают «Отмена» и «Изменение пароля». [ нужна цитата ]
Операция 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» только шифруют обмен данными; они не сверяют имя хоста с именем в предоставленном сертификате. [21]
Операция Abandon требует, чтобы сервер прервал операцию, указанную в идентификаторе сообщения. Серверу не обязательно выполнять запрос. Ни отказ, ни успешно прекращенная операция не отправляют ответ. Аналогичная расширенная операция Cancel отправляет ответы, но не все реализации поддерживают это.
Операция Unbind отменяет все невыполненные операции и закрывает соединение. На него нет ответа. Имя имеет историческое происхождение и не является противоположностью операции Bind. [22]
Клиенты могут прервать сеанс, просто закрыв соединение, но им следует использовать Unbind. [23] Отмена привязки позволяет серверу корректно закрыть соединение и освободить ресурсы, которые в противном случае сохранялись бы в течение некоторого времени, пока не обнаружится, что клиент разорвал соединение. Он также инструктирует сервер отменить операции, которые можно отменить, и не отправлять ответы на операции, которые нельзя отменить. [24]
Существует схема единого идентификатора ресурса (URI) LDAP , которую клиенты поддерживают в той или иной степени, а серверы возвращают ссылки и ссылки продолжения (см. RFC 4516):
ldap://хост:порт/DN?атрибуты?область?фильтр?расширения
Большинство компонентов, описанных ниже, являются дополнительными.
(objectClass=*)как определено в RFC 4515.Например, " 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).
Схема сервера каталогов определяет набор правил, определяющих виды информации, которую может хранить сервер. Он состоит из ряда элементов, в том числе:
Attributes are the elements responsible for storing information in a directory, and the schema defines the rules for which attributes may be used in an entry, the kinds of values that those attributes may have, and how clients may interact with those values.
Clients may learn about the schema elements that the server supports by retrieving an appropriate subschema subentry.
The schema defines object classes. Each entry must have an objectClass attribute, containing named classes defined in the schema. The schema definition of the classes of an entry defines what kind of object the entry may represent - e.g. a person, organization or domain. The object class definitions also define the list of attributes that must contain values and the list of attributes which may contain values.
For example, an entry representing a person might belong to the classes "top" and "person". Membership in the "person" class would require the entry to contain the "sn" and "cn" attributes, and allow the entry also to contain "userPassword", "telephoneNumber", and other attributes. Since entries may have multiple ObjectClasses values, each entry has a complex of optional and mandatory attribute sets formed from the union of the object classes it represents. ObjectClasses can be inherited, and a single entry can have multiple ObjectClasses values that define the available and required attributes of the entry itself. A parallel to the schema of an objectClass is a class definition and an instance in Object-oriented programming, representing LDAP objectClass and LDAP entry, respectively.
Directory servers may publish the directory schema controlling an entry at a base DN given by the entry's subschemaSubentry operational attribute. (An operational attribute describes operation of the directory rather than user information and is only returned from a search when it is explicitly requested.)
Server administrators can add additional schema entries in addition to the provided schema elements. A schema for representing individual people within organizations is termed a white pages schema.
A lot of the server operation is left to the implementor or administrator to decide. Accordingly, servers may be set up to support a wide variety of scenarios.
Например, не указывается хранилище данных на сервере — сервер может использовать плоские файлы, базы данных или просто быть шлюзом к какому-то другому серверу. Контроль доступа не стандартизирован, хотя над этим ведется работа и существуют широко используемые модели. Пароли пользователей могут храниться в их записях или в другом месте. Сервер может отказаться выполнять операции, когда пожелает, и наложить различные ограничения.
Большинство частей LDAP являются расширяемыми. Примеры: Можно определить новые операции. Элементы управления могут изменять запросы и ответы, например, для запроса отсортированных результатов поиска. Могут быть определены новые области поиска и методы привязки. Атрибуты могут иметь параметры , которые могут изменять их семантику.
По мере того, как LDAP набирал обороты, поставщики предоставили его в качестве протокола доступа к другим службам. Затем реализация преобразует данные, чтобы имитировать модель LDAP/X.500, но степень соблюдения этой модели варьируется. Например, существует программное обеспечение для доступа к базам данных SQL через LDAP, хотя LDAP с трудом поддается этому. [25] Серверы X.500 также могут поддерживать LDAP.
Аналогичным образом, данные, ранее хранившиеся в хранилищах данных других типов, иногда перемещаются в каталоги LDAP. Например, информация о пользователях и группах Unix может храниться в LDAP и доступна через модули PAM и NSS . LDAP часто используется другими службами для аутентификации и/или авторизации (какие действия в какой службе может выполнять данный уже аутентифицированный пользователь). Например, в Active Directory Kerberos используется на этапе аутентификации, а LDAP — на этапе авторизации.
Примером такой модели данных является схема GLUE [26] , которая используется в распределенной информационной системе на основе 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.