Lightweight Directory Access Protocol ( LDAP / ˈɛl d æ p / ) — открытый, нейтральный к поставщику, стандартный отраслевой прикладной протокол для доступа и поддержки распределенных информационных служб каталогов по сети Интернет-протокола (IP). [1] Службы каталогов играют важную роль в разработке интрасетей и интернет-приложений, позволяя обмениваться информацией о пользователях, системах, сетях, службах и приложениях по всей сети. [2] Например, службы каталогов могут предоставлять любой организованный набор записей, часто с иерархической структурой, такой как корпоративный каталог электронной почты . Аналогично, телефонный справочник представляет собой список абонентов с адресом и номером телефона.
LDAP указан в серии публикаций Internet Engineering Task Force (IETF) Standard Track, называемых 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] , наборе протоколов, разработанных Международным союзом электросвязи (МСЭ) в 1980-х годах.
Традиционно доступ к службам каталогов X.500 осуществлялся через протокол доступа к каталогам X.500 (DAP), который требовал стека протоколов Open Systems Interconnection (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 и добавил поддержку расширяемости, интегрировал Simple Authentication and Security Layer и лучше согласовал протокол с изданием X.500 1993 года. Дальнейшая разработка самих спецификаций LDAPv3 и многочисленных расширений, добавляющих функции к LDAPv3, осуществлялась через IETF .
На ранних этапах разработки LDAP он был известен как Lightweight Directory Browsing Protocol (легкий протокол просмотра каталогов ) или LDBP . Он был переименован с расширением области действия протокола за пределы просмотра и поиска каталогов, чтобы включить функции обновления каталогов. Он получил свое название Lightweight , потому что он не был таким интенсивным в сети, как его предшественник DAP, и, таким образом, был более легко реализован через Интернет из-за его относительно скромного использования полосы пропускания.
LDAP оказал влияние на последующие интернет-протоколы, включая более поздние версии X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML) и Service Location Protocol (SLP). Он также используется в качестве основы для Microsoft Active Directory .
Клиент начинает сеанс LDAP, подключаясь к серверу LDAP, называемому Directory System Agent (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 givenName : John sn : Doe telephoneNumber : +1 888 555 6789 telephoneNumber : +1 888 555 1232 mail : [email protected] manager : cn=Barbara Doe,dc=example,dc=com objectClass : inetOrgPerson objectClass : organizationalPerson objectClass : person objectClass : top " 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 = пример , dc = com changetype : добавить objectClass : верхний objectClass : персона 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*)))выберет "persons" (элементы 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 changetype : modify add : cn cn : новое-значение-cn-для-добавления - Чтобы заменить значение существующего атрибута, используйте replaceключевое слово. Если атрибут многозначный, клиент должен указать значение атрибута для обновления.
Чтобы удалить атрибут из записи, используйте ключевое слово deleteи указатель changetype modify. Если атрибут многозначный, клиент должен указать значение атрибута для удаления.
Существует также расширение Modify-Increment [18] , которое позволяет увеличивать значение инкрементного атрибута на указанную величину. Следующий пример с использованием LDIF увеличивает employeeNumberна 5:
dn : uid = user.0 , ou = people , dc = example , dc = com changetype : изменить приращение : employeeNumber employeeNumber : 5 - Когда серверы LDAP находятся в реплицированной топологии, клиенты LDAP должны рассмотреть возможность использования контроля после чтения для проверки обновлений вместо поиска после обновления. [19] Контроль после чтения разработан таким образом, что приложениям не нужно отправлять запрос на поиск после обновления — извлекать запись с единственной целью проверки того, что обновление сработало из-за модели согласованности репликации в конечном итоге — плохой тон . Клиент LDAP не должен предполагать, что он подключается к одному и тому же серверу каталогов для каждого запроса, поскольку архитекторы могли разместить балансировщики нагрузки или прокси-серверы LDAP или и то, и другое между клиентами и серверами LDAP.
Изменить DN (переместить/переименовать запись) принимает новое RDN (относительное отличительное имя), опционально DN нового родителя и флаг, указывающий, следует ли удалить значение(я) в записи, которые соответствуют старому RDN. Сервер может поддерживать переименование целых поддеревьев каталогов.
Операция обновления является атомарной: другие операции увидят либо новую запись, либо старую. С другой стороны, LDAP не определяет транзакции нескольких операций: если вы читаете запись, а затем изменяете ее, другой клиент может обновить запись в это время. Однако серверы могут реализовывать расширения [20] , которые поддерживают это.
Extended Operation — это общая операция LDAP, которая может определять новые операции, которые не были частью исходной спецификации протокола. StartTLS — одно из самых значимых расширений. Другие примеры включают Cancel и Password Modify. [ необходима цитата ]
Операция StartTLS устанавливает Transport Layer Security (потомок 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 запрашивает у сервера прерывание операции, названной идентификатором сообщения. Серверу не нужно выполнять запрос. Ни Abandon, ни успешно заброшенная операция не отправляют ответ. Похожая расширенная операция Cancel отправляет ответы, но не все реализации поддерживают это.
Операция Unbind прекращает все невыполненные операции и закрывает соединение. Она не имеет ответа. Название имеет историческое происхождение и не является противоположностью операции Bind. [22]
Клиенты могут прервать сеанс, просто закрыв соединение, но им следует использовать Unbind. [23] Unbind позволяет серверу изящно закрыть соединение и освободить ресурсы, которые он в противном случае хранил бы некоторое время, пока не обнаружит, что клиент покинул соединение. Он также инструктирует сервер отменить операции, которые можно отменить, и не отправлять ответы для операций, которые нельзя отменить. [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).
Схема сервера каталогов определяет набор правил, которые управляют видами информации, которые может хранить сервер. Она имеет ряд элементов, включая:
Атрибуты — это элементы, отвечающие за хранение информации в каталоге, а схема определяет правила, по которым атрибуты могут использоваться в записи, типы значений, которые могут иметь эти атрибуты, и то, как клиенты могут взаимодействовать с этими значениями.
Клиенты могут узнать об элементах схемы, поддерживаемых сервером, извлекая соответствующую подзапись подсхемы.
Схема определяет классы объектов . Каждая запись должна иметь атрибут objectClass, содержащий именованные классы, определенные в схеме. Определение схемы классов записи определяет, какой тип объекта может представлять запись — например, человека, организацию или домен. Определения классов объектов также определяют список атрибутов, которые должны содержать значения, и список атрибутов, которые могут содержать значения.
Например, запись, представляющая человека, может принадлежать классам "top" и "person". Членство в классе "person" потребует, чтобы запись содержала атрибуты "sn" и "cn", и позволит записи также содержать "userPassword", "telephoneNumber" и другие атрибуты. Поскольку записи могут иметь несколько значений ObjectClasses, каждая запись имеет комплекс необязательных и обязательных наборов атрибутов, сформированных из объединения классов объектов, которые она представляет. ObjectClasses могут наследоваться, и одна запись может иметь несколько значений ObjectClasses, которые определяют доступные и требуемые атрибуты самой записи. Параллелью к схеме objectClass является определение класса и экземпляр в объектно-ориентированном программировании , представляющие LDAP objectClass и LDAP entry соответственно.
Серверы каталогов могут публиковать схему каталога, управляющую записью в базовом DN, заданном операционным атрибутом subschemaSubentry записи. ( Операционный атрибут описывает работу каталога, а не информацию о пользователе, и возвращается из поиска только при явном запросе.)
Администраторы сервера могут добавлять дополнительные записи схемы в дополнение к предоставленным элементам схемы. Схема для представления отдельных людей в организациях называется схемой белых страниц .
Большая часть работы сервера остается на усмотрение разработчика или администратора. Соответственно, серверы могут быть настроены для поддержки самых разных сценариев.
Например, хранение данных на сервере не указано — сервер может использовать плоские файлы, базы данных или просто быть шлюзом к какому-то другому серверу. Контроль доступа не стандартизирован, хотя работа над ним велась и существуют общепринятые модели. Пароли пользователей могут храниться в их записях или в другом месте. Сервер может отказаться выполнять операции, когда захочет, и накладывать различные ограничения.
Большинство частей LDAP являются расширяемыми. Примеры: Можно определить новые операции. Элементы управления могут изменять запросы и ответы, например, для запроса отсортированных результатов поиска. Могут быть определены новые области поиска и методы Bind. Атрибуты могут иметь параметры , которые могут изменять их семантику.
По мере того, как 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.