Протокол LDAP: Доступ к распределенным службам каталогов

Введение

Сетевой протокол для поддержки распределенных справочных информационных служб.

Легкий протокол доступа к каталогам (LDAP) – это открытый, независимый от поставщика, отраслевой стандартный протокол прикладного уровня для доступа и обслуживания распределенных справочных информационных служб по сети Интернет-протокола (IP). Справочные службы играют важную роль в разработке интранет- и интернет-приложений, обеспечивая возможность обмена информацией о пользователях, системах, сетях, сервисах и приложениях во всей сети. В качестве примеров, справочные службы могут предоставлять любой структурированный набор записей, часто с иерархической структурой, например, корпоративный каталог электронной почты. Аналогично, телефонный справочник представляет собой список абонентов с адресом и номером телефона. LDAP специфицирован в серии публикаций Internet Engineering Task Force (IETF) на основе стандарта Request for Comments (RFC), с использованием языка описания ASN.1. Последней спецификацией является версия 3, опубликованная как RFC 4511 (обзор технических спецификаций представлен в RFC4510). Распространенное применение LDAP – предоставление централизованного хранилища имен пользователей и паролей. Это позволяет множеству различных приложений и сервисов подключаться к серверу LDAP для аутентификации пользователей. LDAP основан на упрощенном подмножестве стандартов, содержащихся в стандарте X.500. Благодаря этой взаимосвязи, LDAP иногда называют X.500 lite.

История

После 70 лет разработки и управления телефонными справочниками телекоммуникационные компании хорошо понимали требования к каталогам. Эти компании внедрили концепцию каталожных служб в информационные технологии и компьютерные сети, и их вклад вылился в создание всеобъемлющей спецификации X.500 – набора протоколов, разработанных Международным союзом электросвязи (МСЭ) в 1980-х годах. Доступ к каталожным службам X.500 традиционно осуществлялся через протокол доступа к каталогам X.500 (DAP), требовавший использования стека протоколов Open Systems Interconnection (OSI). LDAP изначально задумывался как облегченный альтернативный протокол для доступа к каталожным службам X.500 через более простой (и теперь широко распространенный) стек протоколов TCP/IP. Эта модель доступа к каталогам была заимствована из протоколов DIXIE и Directory Assistance Service. Протокол был первоначально разработан Тимом Хауэсом из Университета Мичигана, Стивом Киллом из Isode Limited, Колином Роббинсом из Nexor и Вэнгиком Йонгом из Performance Systems International примерно в 1993 году как преемник 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 он был известен как протокол облегченного просмотра каталогов, или LDBP. Он был переименован в связи с расширением области применения протокола за пределы просмотра и поиска каталогов, включив в себя функции обновления каталогов. Название "облегченный" он получил, поскольку был менее требователен к сетевым ресурсам, чем его предшественник 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.

Telecommunication companies' understanding of directory requirements were well developed after some 70 years of producing and managing telephone directories. These companies introduced the concept of directory services to information technology and computer networking, their input culminating in the comprehensive X.500 specification, a suite of protocols produced by the International Telecommunication Union (ITU) in the 1980s. X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol (DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler (and now widespread) TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols. The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, Colin Robbins of Nexor and Wengyik Yeong of Performance Systems International, circa 1993, as a successor to DIXIE and DAS. Mark Wahl of Critical Angle Inc., Tim Howes, and Steve Kille started work in 1996 on a new version of LDAP, LDAPv3, under the aegis of the Internet Engineering Task Force (IETF). LDAPv3, first published in 1997, superseded LDAPv2 and added support for extensibility, integrated the Simple Authentication and Security Layer, and better aligned the protocol to the 1993 edition of X.500. Further development of the LDAPv3 specifications themselves and of numerous extensions adding features to LDAPv3 has come through the IETF. In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing Protocol, or LDBP. It was renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include directory update functions. It was given its Lightweight name because it was not as network intensive as its DAP predecessor and thus was more easily implemented over the Internet due to its relatively modest bandwidth usage. LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP). It is also used as the basis for Microsoft's Active Directory.

Изменить DN

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

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

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

Оставь меня .

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

Развязать

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

Схема

Содержание записей в поддереве регулируется схемой каталога — набором определений и ограничений, касающихся структуры информационного дерева каталога (DIT). Схема сервера каталогов определяет набор правил, регулирующих типы информации, которые может хранить сервер. Она включает в себя ряд элементов, таких как:
Синтаксисы атрибутов — предоставляют информацию о типе информации, который может быть сохранен в атрибуте. Правила сопоставления — предоставляют информацию о том, как проводить сравнения со значениями атрибутов. Области применения правил сопоставления — указывают, какие типы атрибутов могут использоваться в сочетании с конкретным правилом сопоставления. Типы атрибутов — определяют идентификатор объекта (OID) и набор имен, которые могут ссылаться на данный атрибут, а также связывают этот атрибут с синтаксисом и набором правил сопоставления. Классы объектов — определяют именованные коллекции атрибутов и классифицируют их на наборы обязательных и необязательных атрибутов. Формы имен — определяют правила для набора атрибутов, которые должны быть включены в RDN для записи. Правила содержания — определяют дополнительные ограничения относительно классов объектов и атрибутов, которые могут использоваться в сочетании с записью. Правило структуры — определяет правила, регулирующие типы подчиненных записей, которые может иметь данная запись. Атрибуты — это элементы, отвечающие за хранение информации в каталоге, и схема определяет правила для атрибутов, которые могут использоваться в записи, типы значений, которые эти атрибуты могут иметь, и способы взаимодействия клиентов с этими значениями. Клиенты могут узнать об элементах схемы, поддерживаемых сервером, путем получения соответствующей подзаписи подсхемы. Схема определяет классы объектов. Каждая запись должна иметь атрибут objectClass, содержащий именованные классы, определенные в схеме. Определение схемы классов записи определяет, какой объект может представлять запись, например, человека, организацию или домен. Определения классов объектов также определяют список атрибутов, которые должны содержать значения, и список атрибутов, которые могут содержать значения. Например, запись, представляющая человека, может принадлежать к классам "top" и "person". Принадлежность к классу "person" требует, чтобы запись содержала атрибуты "sn" и "cn", а также позволяет записи содержать "userPassword", "telephoneNumber" и другие атрибуты. Поскольку записи могут иметь несколько значений ObjectClasses, каждая запись имеет комплекс дополнительных и обязательных наборов атрибутов, сформированных из объединения классов объектов, которые она представляет. ObjectClasses могут быть унаследованы, и одна запись может иметь несколько значений ObjectClasses, определяющих доступные и обязательные атрибуты самой записи. Схема objectClass аналогична определению класса и экземпляру в объектно-ориентированном программировании, представляющим LDAP objectClass и LDAP-запись соответственно. Серверы каталогов могут публиковать схему каталога, контролирующую запись, в базовом DN, заданном оперативным атрибутом subschemaSubentry записи. (Оперативный атрибут описывает работу каталога, а не информацию о пользователе и возвращается только при поиске, если он явно запрошен.) Администраторы сервера могут добавлять дополнительные записи схемы в дополнение к предоставленным элементам схемы. Схема для представления отдельных людей в организациях называется схемой "белых страниц".

The contents of the entries in a subtree are governed by a directory schema, a set of definitions and constraints concerning the structure of the directory information tree (DIT). The schema of a Directory Server defines a set of rules that govern the kinds of information that the server can hold. It has a number of elements, including:
Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute. Matching Rules—Provide information about how to make comparisons against attribute values. Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule. Attribute Types—Define an object identifier (OID) and a set of names that may refer to a given attribute, and associates that attribute with a syntax and set of matching rules. Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes. Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry. Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry. Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have. 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.

Вариации

Большая часть функционирования сервера остается на усмотрение разработчика или администратора. Соответственно, серверы могут быть настроены для поддержки самых разных сценариев. Например, способ хранения данных на сервере не определен – сервер может использовать плоские файлы, базы данных или выступать в качестве шлюза к другому серверу. Контроль доступа не стандартизирован, хотя работы в этом направлении ведутся и существуют общепринятые модели. Пароли пользователей могут храниться в их записях или в другом месте. Сервер может отказаться выполнять операции по своему усмотрению и устанавливать различные ограничения. Большинство компонентов LDAP расширяемы. Примеры: можно определить новые операции. Контроли могут изменять запросы и ответы, например, для запроса отсортированных результатов поиска. Можно определить новые области поиска и методы аутентификации (Bind). Атрибуты могут иметь опции, изменяющие их семантику.

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

По мере распространения 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 для организации – запись SRV в DNS-сервере. Организация с доменом 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 и 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.