Служба каталога (Directory Service) — это программный комплекс для хранения и каталогизации информации. По своей сути это очень похоже на обычную базу данных, но с “уклоном” скорее на чтение данных, нежели на их добавление или модификацию. Обычно служба каталога базируется на клиент-серверной архитектуре. Одна из наиболее известных таких систем — это DNS (Domain Name Service): DNS-сервер производит взаимную “трансляцию” имён машин и их IP-адресов. Другие машины в сети могут обращаться к такому серверу за информацией о соответствии имени и адреса. Однако это очень простой пример каталогизации информации. Объекты в такой базе имеют ограниченное количество атрибутов — таких как имя, адрес и ещё несколько дополнительных параметров. Разумеется, служба каталога какого-нибудь предприятия будет содержать более разнообразные данные и иметь гораздо более сложную структуру.
В общем случае, служба каталога должна предоставлять простой, централизованный доступ к данным, которые могут использоваться различными приложениями. Протокол, по которому могла бы работать такая служба, был разработан в ISO (International Standartization Organization), получил номер X.500 и назывался DAP (Directory Access Protocol). В соответствии с этим протоколом любое приложение может получить доступ к информации в каталоге. Там же была предложена гибкая и легко расширяемая информационная структура которая позволяла хранить в принципе любой тип данных. К сожалению, X.500 имел и ряд ограничений, таких как зависимость от коммуникационного уровня, который не являлся стандартным протоколом TCP и запутанность требований к правилам именования объектов. В результате решение на базе этого протокола становилось очень дорогим при обслуживании.
Позже появился протокол LDAP (Lightweight Directory Access Protocol), который позволил реализовать доступ по TCP/IP и мог легко расширяться. В результате появилось решение, позволяющее организовать службу каталога на предприятии любого масштаба.
Сегодня существует несколько реализаций данного протокола от различных фирм. Наиболее известные из них — это Netscape Directory Service™, Microsoft Active Directory™, Novell Directory Service™. Из некоммерческих реализаций LDAP наибольшее распространение получил проект OpenLDAP. Именно его мы и будем рассматривать в данной главе, хотя большинство понятий и определений применимо и к другим реализациям сервера LDAP.
Для понимания работы службы каталога необходимо усвоить несколько ключевых терминов.
Данные каталога хранятся в виде объектов или сущностей (от англ. entry), состоящих из специальных полей называемых атрибутами (attributes). Набор атрибутов, их синтаксис и правила поиска определяются схемой каталога (scheme). Все объекты каталога идентифицируются специальным атрибутом — DN (Distinguished Name).
Данные в каталоге можно представить в виде древовидной структуры — DIT (Directory Information Tree). Это очень похоже на структуру, используемую многими файловыми системами. Вершиной такого дерева является корневой объект (Root Entry). DN корневого объекта одновременно является суффиксом каталога.
Каждый последующий объект в структуре каталога идентифицируется уникальным значением DN который описывает путь к объекту в каталоге. Если продолжить аналогию с файловой системой то DN любого объекта так же включает DN всех объектов стоящих выше по иерархии. Отличие в данном случае только в том, что DN формируется не слева направо, как путь к файлу, а наоборот — справа налево.
DN администратора каталога (Root Distinguished Name) — это специальный объект, описывающий администратора каталога. Этот объект указывается в конфигурации сервера, но может отсутствовать в самом каталоге. К такому объекту не применяются списки доступа (ACL). В некоторых реализациях LDAP такой объект может не иметь суффикса.
База поиска (Base Distinguished Name) — объект каталога, начиная с которого производится поиск. Дело в том, что не всегда есть необходимость производить поиск по всему дереву каталога; ограничить область поиска можно указанием в запросе базы поиска. По умолчанию этот параметр соответствует суффиксу.
Серверы LDAP могут поставляться с несколькими вариантами бэкенда (backend). Например, OpenLDAP имеет такие варианты, как LDBM — собственный формат хранения данных в текстовых файлах; SHELL — интерфейс к базе данных, использующий команды UNIX; PASSWD — простейшая база, использующая стандартные файлы /etc/passwd и /etc/group; SQL — интерфейс к любой базе данных, использующей SQL.
Для процедур импорта и экспорта данных всеми серверами LDAP поддерживается единый формат обмена данными — LDIF. Вот пример такого файла с описанием двух объектов:
dn: dc=example,dc=com
objectClass: top
objectClass: organization
o: example.com
o: Example Inc.
dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: People
description: Example Inc. workers
description: Stuff area
Описание каждого объекта в таком файле начинается с атрибута DN. Специальный атрибут objectClass указывает, к каким классам относится данный объект и, следовательно, какие атрибуты он может иметь. В нашем случае принадлежность к классу top означает, что объект обязательно должен иметь атрибут objectClass, а принадлежность к классу organization предполагает наличие нескольких атрибутов, из которых атрибут o является обязательным.
Второй объект находится на одну ступеньку ниже по иерархии и поэтому в его DN включён DN объекта верхнего уровня. Этот объект относится к классу organizationalUnit и поэтому имеет обязательный атрибут ou.
Можно заметить что некоторые атрибуты (для которых это применимо) могут иметь несколько значений. В данном примере атрибут description имеет два значения. А вот для атрибута dn допустимо только одно значение.
Классы, характеризующие объекты, и атрибуты, составляющие классы, описываются схемой базы. Её пример приведён ниже.
attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' )
SUP name
)
attributetype ( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
objectclass ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL
MUST o
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
postalAddress $ physicalDeliveryOfficeName $ st $ l $ description
)
)
В данном фрагменте приводятся описания двух атрибутов и одного класса. Вот что означают эти записи:
Атрибут o (его можно также называть organizationName) является расширением атрибута name.
Атрибут description — это строка длиной до 1024 байт; при поиске в ней регистр символов не учитывается.
Класс organization является расширением класса top и имеет единственный обязательный атрибут o. Кроме того имеется большое количество необязательных атрибутов таких как userPassword, businessAddress, street, postOfficeBox и т.д.
Много полезной информации о схемах можно найти по ссылкам на сайте OpenLDAP.