Войти
Облегченный протокол доступа к каталогам (LDAP ) - это открытый, не зависящий от производителя, отраслевой стандарт протокол приложений для доступа и обслуживания распределенных справочных информационных служб через Интернет-протокол (IP) сеть. Службы каталогов играют важную роль в разработке интрасети и Интернет-приложений, позволяя обмениваться информацией о пользователях, системах, сетях, службах и приложения по всей сети. Например, службы каталогов могут предоставлять любой организованный набор записей, часто с иерархической структурой, такой как корпоративный каталог электронной почты. Аналогично, телефонный справочник - это список абонентов с адресом и номером телефона.
LDAP указан в серии публикаций Internet Engineering Task Force (IETF) Standard Track под названием Request for Comments (RFC) с использованием языка описания АСН.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 и Wengyik Yeong из Performance Systems International, около 1993 года, в качестве преемника DIXIE и DAS. Марк Уол из Critical Angle Inc., Тим Хоуз и Стив Килле в 1996 году начали работу над новой версией LDAP, LDAPv3, под эгидой Internet Engineering Task Принудительно (IETF). Протокол LDAPv3, впервые опубликованный в 1997 году, заменил LDAPv2 и добавил поддержку расширяемости, интегрировал Simple Authentication and Security Layer и лучше согласовал протокол с версией X.500 1993 года. Дальнейшее развитие самих спецификаций LDAPv3 и многочисленных расширений, добавляющих функции LDAPv3, было осуществлено посредством IETF.
. На ранних этапах разработки LDAP он был известен как протокол облегченного просмотра каталогов или LDBP. Он был переименован с расширением области действия протокола, выходящей за пределы просмотра и поиска каталогов, и теперь включает функции обновления каталогов. Ему было дано название Lightweight, потому что он не требовал такой интенсивной работы в сети, как его предшественник DAP, и поэтому его было легче реализовать через Интернет из-за относительно небольшого использования полосы пропускания.
LDAP повлиял на последующие Интернет-протоколы, включая более поздние версии X.500, XML Enabled Directory (XED), язык разметки службы каталогов (DSML), Язык разметки предоставления услуг (SPML) и Протокол определения местоположения услуг (SLP). Он также используется в качестве основы для Microsoft Active Directory.
. Клиент запускает сеанс LDAP, подключаясь к серверу LDAP, который называется Агент системы каталогов (DSA), по умолчанию на TCP и UDP порт 389 или на порт 636 для LDAPS (LDAP через SSL, см. ниже). Затем клиент отправляет серверу запрос операции, а сервер отправляет ответы в ответ. За некоторыми исключениями, клиенту не нужно ждать ответа перед отправкой следующего запроса, и сервер может отправлять ответы в любом порядке. Вся информация передается с использованием Базовых правил кодирования (BER).
Клиент может запросить следующие операции:
Кроме того, сервер может отправлять «Незапрошенные уведомления», которые не ответы на запросы, например до истечения времени ожидания соединения.
Обычным альтернативным методом защиты связи LDAP является использование SSL туннеля. Порт по умолчанию для LDAP через SSL - 636. Использование LDAP через SSL было обычным явлением в LDAP версии 2 (LDAPv2), но никогда не было стандартизировано в какой-либо формальной спецификации. Это использование устарело вместе с LDAPv2, который был официально прекращен в 2003 году. Глобальный каталог доступен по умолчанию на портах 3268 и 3269 для LDAPS.
Протокол предоставляет интерфейс с каталогами, соответствующими редакции 1993 г. модели X.500 :
/foo/bar/myfile.txtбыло DN, то myfile.txtбудет RDN).DN может измениться за время существования записи, например, когда записи перемещаются внутри дерева. Чтобы надежно и однозначно идентифицировать записи, в наборе операционных атрибутов записи может быть предоставлен UUID.
Запись может выглядеть следующим образом, если она представлена в формате обмена данными LDAP (LDIF) (сам LDAP является двоичным протоколом ):
dn : cn = John Doe, dc = example, dc = com cn: John Doe givenName: John sn: Doe phoneNumber: +1888555 6789 phoneNumber: +1888555 1232 mail: [email#160;protected] менеджер: cn = Barbara Doe, dc = example, dc = com objectClass: inetOrgPerson objectClass: organizationPerson objectClass: person objectClass: top
"dn"- отличительное имя записи; это не атрибут и не часть записи." cn = John Doe"- это RDN (относительное отличительное имя) записи, а" dc = example, dc = com"- DN родительской записи, где" dc" обозначает 'Компонент домена '. В других строках показаны атрибуты в записи. Имена атрибутов обычно представляют собой мнемонические строки, например «cn» для общего имени, «dc"для компонента домена," mail"для адреса электронной почты и" sn"для фамилии.
Сервер h olds поддерево, начиная с определенной записи, например «dc = example, dc = com» и его дочерние элементы. Серверы также могут содержать ссылки на другие серверы, поэтому попытка доступа к «ou = Department, dc = example, dc = com» может вернуть ссылку или продолжение ссылки на сервер, который содержит эту часть каталога. дерево. Затем клиент может связаться с другим сервером. Некоторые серверы также поддерживают цепочку, что означает, что сервер связывается с другим сервером и возвращает результаты клиенту.
LDAP редко определяет какой-либо порядок: сервер может возвращать значения атрибута, атрибуты в записи и записи, найденные операцией поиска, в любом порядке. Это следует из формальных определений - запись определяется как набор атрибутов, а атрибут - это набор значений, и наборы не нужно упорядочивать.
Операция ADD вставляет новую запись в базу данных сервера каталогов. Если отличительное имя в запросе на добавление уже существует в каталоге, то сервер не будет добавлять повторяющуюся запись, а установит код результата в результате добавления как десятичное 68, «entryAlreadyExists».
dn: uid = user, ou = people, dc = example, dc = com changetype: add objectClass: top objectClass : person uid: user sn: last-name cn: common-name userPassword: password
В приведенном выше примере 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.
BIND также устанавливает версию протокола LDAP, отправляя номер версии в виде целого числа. Если клиент запрашивает версию, которую сервер не поддерживает, сервер должен установить код результата в ответе BIND на код ошибки протокола. Обычно клиенты должны использовать LDAPv3, который используется по умолчанию в протоколе, но не всегда в библиотеках LDAP.
BIND должна была быть первой операцией в сеансе в LDAPv2, но в LDAPv3 она не требуется. В LDAPv3 каждый успешный запрос BIND изменяет состояние аутентификации сеанса, а каждый неудачный запрос BIND сбрасывает состояние аутентификации сеанса.
Чтобы удалить запись, клиент LDAP передает правильно сформированный запрос на удаление на сервер.
hasSubordinates, значение которого указывает, имеет ли запись какие-либо подчиненные записи, а некоторые серверы поддерживают рабочий атрибут numSubordinates, указывающий количество записей, подчиненных записи, содержащей 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 внес изменения в существующие записи. Попытки изменить несуществующие записи потерпят неудачу. Запросы MODIFY подлежат контролю доступа, реализованному на сервере.
Операция MODIFY требует, чтобы было указано отличительное имя (DN) записи и последовательность изменений. Каждое изменение в последовательности должно быть одним из:
LDIF пример добавления значения к атрибуту:
dn: dc = example, dc = com changetype: modify add: cn cn: the- new-cn-value-to-be-added -
Чтобы заменить значение существующего атрибута, используйте ключевое слово replace. Если атрибут является многозначным, клиент должен указать значение атрибута для обновления.
Чтобы удалить атрибут из записи, используйте ключевое слово deleteи указатель типа изменения modify. Если атрибут многозначный, клиент должен указать значение удаляемого атрибута.
Существует также расширение Modify-Increment, которое позволяет увеличивать значение атрибута на заданную величину. В следующем примере с использованием LDIF приращение employeeNumberна 5:
dn: uid = user.0, ou = people, dc = example, dc = com changetype: modify increment: employeeNumber employeeNumber: 5 -
Когда серверы LDAP находятся в реплицированной топологии, клиенты LDAP должны рассмотреть возможность использования управления после чтения для проверки обновлений вместо поиска после обновления. Элемент управления после считывания разработан таким образом, что приложениям не нужно отправлять поисковый запрос после обновления - это плохой тайт - получать запись с единственной целью проверки того, что обновление работает из-за репликации конечная согласованность модель. Клиент LDAP не должен предполагать, что он подключается к одному и тому же серверу каталогов для каждого запроса, потому что архитекторы могли разместить балансировщики нагрузки или прокси LDAP или и то, и другое между клиентами и серверами LDAP.
Modify DN (перемещение / переименование записи) принимает новое RDN (относительное отличительное имя), необязательно новое родительское DN и флаг, который указывает, следует ли удалить значение (значения)) в записи, соответствующей старому RDN. Сервер может поддерживать переименование целых поддеревьев каталогов.
Операция обновления является атомарной: другие операции будут видеть либо новую запись, либо старую. С другой стороны, LDAP не определяет транзакции, состоящие из нескольких операций: если вы читаете запись, а затем изменяете ее, другой клиент, возможно, тем временем обновил запись. Однако серверы могут реализовывать расширения, поддерживающие это.
Расширенная операция - это общая операция LDAP, которая может определять новые операции, которые не были частью исходной спецификации протокола. StartTLS - одно из самых значительных расширений. Другие примеры включают «Отмена» и «Изменение пароля».
Операция StartTLS устанавливает Transport Layer Security (потомок SSL ) в соединении. Он может обеспечивать конфиденциальность данных (для защиты данных от наблюдения третьими лицами) и / или защиту целостности данных (которая защищает данные от подделки). Во время согласования TLS сервер отправляет свой сертификат X.509 для подтверждения своей личности. Клиент также может отправить сертификат для подтверждения своей личности. После этого клиент может использовать SASL / EXTERNAL. Используя SASL / EXTERNAL, клиент запрашивает у сервера свою идентичность из учетных данных, предоставленных на более низком уровне (например, TLS). Хотя технически сервер может использовать любую идентификационную информацию, установленную на любом более низком уровне, обычно сервер будет использовать идентификационную информацию, установленную TLS.
Серверы также часто поддерживают нестандартный протокол «LDAPS» («Безопасный LDAP», широко известный как «LDAP через SSL») на отдельном порту, по умолчанию 636. LDAPS отличается от LDAP двумя способами: 1) при подключении клиент и сервер устанавливают TLS до того, как будут переданы какие-либо сообщения LDAP (без операции StartTLS) и 2) соединение LDAPS должно быть закрыто после закрытия TLS.
Некоторые клиентские библиотеки LDAPS только шифруют обмен данными; они не сверяют имя хоста с именем в предоставленном сертификате.
Операция Abandon требует, чтобы сервер прервал операцию, названную идентификатором сообщения. Серверу не нужно выполнять запрос. Ни «Отказ», ни успешно прерванная операция не отправляют ответа. Аналогичная расширенная операция Cancel отправляет ответы, но не все реализации это поддерживают.
Операция Unbind отменяет все невыполненные операции и закрывает соединение. Нет ответа. Имя имеет историческое происхождение и не является противоположностью операции привязки.
Клиенты могут прервать сеанс, просто закрыв соединение, но они должны использовать команду «Отменить привязку». Unbind позволяет серверу корректно закрыть соединение и освободить ресурсы, которые в противном случае он оставил бы в течение некоторого времени, пока не обнаружит, что клиент отказался от соединения. Он также указывает серверу отменять операции, которые можно отменить, и не отправлять ответы для операций, которые нельзя отменить.
Универсальный идентификатор ресурса LDAP (URI) существует схема, которую клиенты поддерживают в разной степени, и серверы возвращают в ссылках и ссылках продолжения (см. RFC 4516 ):
ldap: // host: port / DN? ? scope? filter? extension
Большинство описанных ниже компонентов являются необязательными.
(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-адресах, специальные символы должны быть закодированы в процентах.
Существует аналогичная нестандартная схема URI ldapsдля LDAP через SSL. Это не следует путать с LDAP с TLS, который достигается с помощью операции StartTLS с использованием стандартной схемы ldap.
Содержимое записей в поддереве регулируется схемой каталога, набором определений и ограничений, касающихся структуры дерева информации каталога (DIT).
Схема сервера каталогов определяет набор правил, которые управляют видами информации, которую может хранить сервер. Он имеет ряд элементов, в том числе:
Атрибуты - это элементы, отвечающие за хранение информации в каталоге, а схема определяет правила, для которых атрибуты могут использоваться в записи, типы значений, которые могут иметь эти атрибуты, и как клиенты могут взаимодействовать с этими ценностями.
Клиенты могут узнать об элементах схемы, которые поддерживает сервер, извлекая соответствующую подстатью подсхемы.
Схема определяет классы объектов. Каждая запись должна иметь атрибут objectClass, содержащий именованные классы, определенные в схеме. Определение схемы классов записи определяет, какой тип объекта может представлять запись - например, человек, организация или домен. Определения классов объектов также определяют список атрибутов, которые должны содержать значения, и список атрибутов, которые могут содержать значения.
Например, запись, представляющая человека, может принадлежать к классам «верхний» и «человек». Членство в классе «person» потребует, чтобы запись содержала атрибуты «sn» и «cn», а также позволило бы записи также содержать «userPassword», «phoneNumber» и другие атрибуты. Поскольку записи могут иметь несколько значений ObjectClasses, каждая запись имеет комплекс необязательных и обязательных наборов атрибутов, сформированных из объединения классов объектов, которые она представляет. 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 может использовать 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 = Местонахождение, ou = Некоторая организационная единица, o = Некоторая организация, c = FR, или в США: cn = Общее название, l = Местонахождение, ou = Некоторая организационная единица, o = Некоторая организация, st = CA, c = US.
