Поиск по сайту:

Понимание протокола LDAP, иерархии данных и компонентов ввода

Введение

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

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

Что такое служба каталогов?

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

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

Что такое LDAP?

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

Поскольку LDAP является открытым протоколом, доступно множество различных реализаций. Проект OpenLDAP — один из наиболее хорошо поддерживаемых вариантов с открытым исходным кодом.

Основные компоненты данных LDAP

Выше мы обсуждали, что LDAP — это протокол, используемый для связи с базой данных каталогов для запроса, добавления или изменения информации. Однако это простое определение искажает сложность систем, поддерживающих этот протокол. То, как LDAP отображает данные для пользователей, очень зависит от взаимодействия и отношений между некоторыми определенными структурными компонентами.

Атрибуты

Сами данные в системе LDAP в основном хранятся в элементах, называемых атрибутами. Атрибуты в основном представляют собой пары ключ-значение. В отличие от некоторых других систем, ключи имеют предопределенные имена, которые диктуются объектными классами, выбранными для ввода (мы обсудим это немного позже). Кроме того, данные в атрибуте должны соответствовать типу, указанному в исходном определении атрибута.

Установка значения атрибута выполняется с помощью имени атрибута и значения атрибута, разделенных двоеточием и пробелом. Пример атрибута с именем mail, который определяет адрес электронной почты, будет выглядеть следующим образом:

mail: admin@example.com

При обращении к атрибуту и его данным (если он не установлен) две стороны вместо этого соединяются знаком равенства:

mail=example.com

Значения атрибутов содержат большую часть фактических данных, которые вы хотите хранить и получать к ним доступ в системе LDAP. Другие элементы LDAP используются для структуры, организации и т. д.

Записи

Атрибуты сами по себе не очень полезны. Чтобы иметь значение, они должны быть связаны с чем-то. В LDAP вы используете атрибуты внутри записи. Запись в основном представляет собой набор атрибутов под именем, используемым для описания чего-либо.

Например, у вас может быть запись для пользователя в вашей системе или для каждого предмета в инвентаре. Это примерно аналогично строке в системе реляционной базы данных или одной странице в адресной книге (здесь атрибуты будут представлять различные поля в каждой из этих моделей). В то время как атрибут определяет качество или характеристику чего-либо, запись описывает сам элемент, просто собирая эти атрибуты под именем.

Пример записи, отображаемой в формате LDIF (формат обмена данными LDAP), будет выглядеть примерно так:

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com
objectclass: person
sn: Ellingwood
cn: Justin Ellingwood

Приведенный выше пример может быть допустимой записью в системе LDAP.

ДИТ

По мере того, как вы начинаете знакомиться с LDAP, легко понять, что данные, определяемые атрибутами, представляют собой лишь часть доступной информации об объекте. Остальное определяется размещением записи в системе LDAP и связанными с ней отношениями.

Например, если можно иметь записи как для пользователя, так и для элемента инвентаря, как кто-то сможет отличить их друг от друга? Один из способов различить записи разных типов — установить отношения и группы. Это во многом зависит от того, где размещается запись при ее создании. Все записи добавляются в систему LDAP в виде ветвей деревьев, называемых информационными деревьями данных или DIT.

DIT представляет собой организационную структуру, аналогичную файловой системе, где каждая запись (кроме записи верхнего уровня) имеет только одну родительскую запись и может иметь любое количество дочерних записей под ней. Поскольку записи в дереве LDAP могут представлять что угодно, некоторые записи будут использоваться в основном для организационных целей, подобно каталогам в файловой системе.

Таким образом, у вас может быть запись для «людей» и запись для «предметов инвентаря». Ваши фактические записи данных могут быть созданы как дочерние элементы, чтобы лучше различать их тип. Ваши организационные записи могут быть определены произвольно, чтобы наилучшим образом представить ваши данные.

В примере записи в последнем разделе мы видим одно указание DIT в строке dn:

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com

Эта строка называется отличительным именем записи (подробнее об этом позже) и используется для идентификации записи. Он действует как полный обратный путь к корню DIT. В данном случае у нас есть запись с именем sn=Ellingwood, которую мы создаем. Прямой родитель — это запись с именем ou=people, которая, вероятно, используется в качестве контейнера для записей, описывающих людей. Родительские элементы этой записи получены из доменного имени linux-console.net, которое функционирует как корень нашего DIT.

Определение компонентов данных LDAP

В последнем разделе мы обсудили, как данные представлены в системе LDAP. Однако мы также должны поговорить о том, как определяются компоненты, в которых хранятся данные. Например, мы упомянули, что данные должны соответствовать типу, определенному для каждого атрибута. Откуда берутся эти определения? Давайте снова начнем снизу с точки зрения сложности и будем двигаться вверх.

Определения атрибутов

Атрибуты определяются с использованием достаточно сложного синтаксиса. Они должны указывать имя атрибута, любые другие имена, которые могут использоваться для ссылки на атрибут, тип данных, которые могут быть введены, а также множество других метаданных. Эти метаданные могут описывать атрибут, сообщать LDAP, как сортировать или сравнивать значение атрибута, и сообщать, как он соотносится с другими атрибутами.

Например, это определение для атрибута name:

attributetype ( 2.5.4.41 NAME 'name' DESC 'RFC4519: common supertype of name attributes'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

name — это имя атрибута. Число в первой строке — это глобально уникальный OID (идентификатор объекта), присвоенный атрибуту, чтобы отличать его от любого другого атрибута. Остальная часть записи определяет, как запись может сравниваться во время поиска, и имеет указатель, указывающий, где найти информацию для требований к типу данных атрибута.

Одной из важных частей определения атрибута является возможность определения атрибута более одного раза в записи. Например, в определении может быть указано, что фамилия может быть определена только один раз для каждой записи, но атрибут «племянница» может позволять определять этот атрибут несколько раз в одной записи. По умолчанию атрибуты являются многозначными и должны содержат флаг SINGLE-VALUE, если они могут быть установлены только один раз для каждой записи.

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

Определения объектных классов

Атрибуты собираются внутри сущностей, называемых объектными классами. Объектные классы — это просто группы связанных атрибутов, которые могут быть полезны при описании конкретной вещи. Например, «человек» — это объектный класс.

Записи получают возможность использовать атрибуты объектного класса, устанавливая специальный атрибут с именем objectClass, называя объектный класс, который вы хотите использовать. Фактически, objectClass — это единственный атрибут, который вы можете установить в записи, не указывая дополнительный объектный класс.

Таким образом, если вы создаете запись для описания человека, включая objectClass person (или любой из более конкретных классов объектов, полученных от человека — мы рассмотрим это позже), вы можете использовать все атрибуты. внутри этого объектного класса:

dn: . . .
objectClass: person

Затем у вас будет возможность установить эти атрибуты в записи:

  • cn: обычное имя
  • описание: удобочитаемое описание записи.
  • seeAlso: ссылка на связанные записи
  • sn: фамилия
  • номер телефона: номер телефона.
  • userPassword: пароль пользователя.

Атрибут objectClass можно использовать несколько раз, если вам нужны атрибуты из разных объектных классов, но существуют правила, определяющие, что является приемлемым. Объектные классы определяются как один из нескольких «типов».

Два основных типа ObjectClasses — структурные и вспомогательные. Запись должна иметь ровно один структурный класс, но может иметь ноль или более вспомогательных классов, используемых для расширения атрибутов, доступных для класса. Структурный объектный класс используется для создания и определения записи, а вспомогательные объектные классы добавляют дополнительные функциональные возможности за счет дополнительных атрибутов.

Определения ObjectClass определяют, являются ли атрибуты, которые они предоставляют, обязательными (указывается спецификацией MUST) или необязательными (указывается спецификацией MAY). Несколько объектных классов могут предоставлять одни и те же атрибуты, а категоризация атрибута MAY или MUST может варьироваться от объектного класса к объектному классу.

Например, объектный класс person определяется следующим образом:

objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Он определяется как структурный объектный класс, что означает, что его можно использовать для создания записи. Созданная запись должна устанавливать атрибуты surname и commonname и может выбрать установку userPassword, phoneNumber, seeAlso или description.

Схемы

Определения ObjectClass и определения атрибутов, в свою очередь, сгруппированы в конструкцию, известную как схема. В отличие от традиционных реляционных баз данных схемы в LDAP представляют собой просто наборы связанных объектных классов и атрибутов. Одно DIT может иметь множество различных схем, чтобы создавать необходимые записи и атрибуты.

Схемы часто включают дополнительные определения атрибутов и могут требовать атрибутов, определенных в других схемах. Например, объектный класс person, который мы обсуждали выше, требует, чтобы атрибут surname или sn был установлен для любых записей, использующих person объектный класс. Если они не определены на самом сервере LDAP, схема, содержащая эти определения, может использоваться для добавления этих определений в словарь сервера.

Формат схемы — это, по сути, просто комбинация приведенных выше записей, например:

. . .

objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
  DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )

attributetype ( 2.5.4.4 NAME ( 'cn' 'commonName' )
  DESC 'RFC4519: common name(s) for which the entity is known by' SUP name )

. . .

Организация данных

Мы рассмотрели общие элементы, которые используются для создания записей в системе LDAP, и рассказали о том, как эти строительные блоки определяются в системе. Однако мы еще мало говорили о том, как организована и структурирована сама информация в LDAP DIT.

Размещение записей в DIT

DIT — это просто иерархия, описывающая взаимосвязь существующих записей. После создания каждая новая запись должна «прицепиться» к существующему DIT, став дочерним элементом существующей записи. Это создает древовидную структуру, которая используется для определения отношений и присвоения значения.

Вершина DIT — это самая широкая категоризация, по которой каждый последующий узел так или иначе является потомком. Как правило, самая верхняя запись просто используется как метка, указывающая на организацию, для которой используется DIT. Эти записи могут относиться к любым желаемым объектным классам, но обычно они создаются с использованием компонентов домена (dc=example,dc=com для управляющей информации LDAP, связанной с example.com) , местоположения (l=new_york,c=us для организации или сегмента в Нью-Йорке) или организационные сегменты (ou=marketing,o=Example_Co).

Записи, используемые для организации (используемые как папки), часто используют объектный класс OrganizationUnit, который позволяет использовать простую описательную метку атрибута с именем ou=. Они часто используются для общих категорий в записи DIT верхнего уровня (например, ou=people, ou=groups и ou=inventory ). распространены). LDAP оптимизирован для поиска информации вдоль дерева, а не вверх и вниз по дереву, поэтому часто лучше сохранять иерархию DIT довольно неглубокой, с общими организационными ветвями и дополнительными подразделениями, указываемыми посредством назначения определенных атрибутов.

Именование и ссылки на записи в DIT

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

Для однозначной ссылки на запись вы используете RDN записи в сочетании с RDN всех ее родительских записей. Эта цепочка RDN ведет обратно к вершине иерархии DIT и обеспечивает однозначный путь к рассматриваемой записи. Мы называем эту цепочку RDN отличительным именем записи или DN. Вы должны указать DN для записи во время создания, чтобы система LDAP знала, где разместить новую запись, и могла гарантировать, что RDN записи уже не используется другой записью.

В качестве аналогии вы можете думать о RDN как об относительном имени файла или каталога, как в файловой системе. С другой стороны, DN больше похож на абсолютный путь. Важным отличием является то, что DN LDAP содержат наиболее конкретное значение с левой стороны, а пути к файлам содержат наиболее конкретную информацию с правой стороны. DN разделяют значения RDN запятой.

Например, запись о человеке по имени Джон Смит может быть помещена под записью \Люди для организации в разделе example.com. Поскольку в организации может быть несколько Джонов Смитов, идентификатор пользователя может быть лучшим выбором для RDN записи. Запись может быть указана следующим образом:

dn: uid=jsmith1,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: jsmith1

Нам пришлось использовать объектный класс inetOrgPerson, чтобы получить доступ к атрибуту uid в этом экземпляре (у нас все еще есть доступ ко всем атрибутам, определенным в person ). objectClass, как мы увидим в следующем разделе).

Наследование LDAP

Когда дело доходит до этого, большая часть того, как данные в системе LDAP соотносятся друг с другом, является вопросом иерархии, наследования и вложенности. LDAP поначалу многим кажется необычным, потому что в его структуре реализованы некоторые объектно-ориентированные концепции. В основном это происходит из-за использования классов, как мы обсуждали ранее, и доступности наследования, о котором мы поговорим сейчас.

Наследование объектного класса

Каждый объектный класс — это класс, описывающий характеристики объектов этого типа.

Однако, в отличие от простого наследования, объекты в LDAP могут быть и часто являются экземплярами нескольких классов (некоторые языки программирования обеспечивают аналогичную функциональность посредством множественного наследования). Это возможно, потому что концепция класса LDAP — это просто набор атрибутов, которые он ДОЛЖЕН или МОЖЕТ иметь. Это позволяет указать несколько классов для записи (хотя может и должен присутствовать только один объектный класс STRUCTURAL), в результате чего объект просто имеет доступ к объединенной коллекции атрибутов с самым строгим объявлением MUST или MAY. имеет приоритет.

В своем определении объектный класс может идентифицировать родительский объектный класс, от которого наследуются его атрибуты. Это делается с помощью SUP, за которым следует объектный класс для наследования. Например, объектный класс organizationalPerson начинается так:

objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
 . . .

Объектный класс, следующий за идентификатором SUP, является родительским объектным классом. Родительский объект должен совместно использовать тип объектного класса определяемого объектного класса (например, STRUCTURAL или AUXILIARY). Дочерний объектный класс автоматически наследует атрибуты и требования к атрибутам родителя.

При назначении объектного класса в записи вам нужно только указать наиболее конкретного потомка в цепочке наследования, чтобы иметь доступ ко всем атрибутам. В последнем разделе мы использовали это, чтобы указать inetOrgPerson в качестве единственного объектного класса для нашей записи John Smith, сохраняя при этом доступ к атрибутам, определенным в person и organizationalPerson. объектные классы. Иерархия наследования inetOrgPerson выглядит следующим образом:

inetOrgPerson -> organizationalPerson -> person -> top

Почти все деревья наследования объектных классов заканчиваются специальным объектным классом, называемым \top. Это абстрактный объектный класс, единственной целью которого является требование, чтобы был установлен сам объектный класс. Он используется для обозначения вершины цепочки наследования.

Наследование атрибутов

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

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

Это полезно, потому что позволяет создать определенный атрибут, полезный для людей, интерпретирующих элемент, даже если его общая форма остается неизменной. Наследование атрибута surname, которое мы обсуждали здесь, помогает людям различать фамилию и более общее имя, но кроме значения значения, между фамилией и именем для системы LDAP мало различий.

Варианты протокола LDAP

Мы упомянули в начале, что LDAP — это на самом деле просто протокол, определяющий коммуникационный интерфейс для работы со службами каталогов. Обычно он известен как протокол LDAP или ldap.

Стоит отметить, что вы можете увидеть некоторые варианты в обычном формате:

  • ldap://: это базовый протокол LDAP, обеспечивающий структурированный доступ к службе каталогов.
  • ldaps://: этот вариант используется для обозначения LDAP через SSL/TLS. Обычный трафик LDAP не шифруется, хотя большинство реализаций LDAP поддерживают это. Этот метод шифрования соединений LDAP фактически устарел, и вместо него рекомендуется использовать шифрование STARTTLS. Если вы используете LDAP в незащищенной сети, настоятельно рекомендуется использовать шифрование.
  • ldapi://: используется для указания LDAP через IPC. Это часто используется для безопасного подключения к локальной системе LDAP в административных целях. Он обменивается данными через внутренние сокеты, а не через открытый сетевой порт.

Все три формата используют протокол LDAP, но последние два содержат дополнительную информацию о том, как он используется.

Заключение

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