Объектные классы. 
Работа протокола Lightweight Directory Access Protocol

Объектные классы являются, по существу, пакетами атрибутов. Существует огромное число предопределённых объектных классов, в каждом из которых полным-полно атрибутов для почти всех возможных применений каталогов LDAP. Однако, само собой разумеется, что среди всех этих предопределённых объектных классов, нет того, который Вам просто необходим. У объектных классов есть ещё две характеристики:

• 1. Объектный класс определяет, должен ли входящий в него атрибут присутствовать в записи (обязательный атрибут), или он может присутствовать (необязательный атрибут).
• 2. Объектный класс может быть частью иерархии, в этом случае он наследует все характеристики своих родительских объектных классов.

Вот неполный список наиболее часто используемых объектных классов и их атрибутов.

Описание дерева и добавление данных

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

Описание древовидной структуры и первоначальное наполнение данными осуществляется путем добавления записей, начиная от корневой записи DIT и двигаясь вниз по иерархии. Таким образом, родительская запись всегда должна быть добавлена перед тем, как пытаться добавить дочерние записи. Добавление записей может происходить разными путями, один из которых?—?использовать файлы формата LDAP Data Interchange Files (LDIF), который полностью описан в одной из последующих глав. Файлы LDIF?—?это текстовые файлы, описывающие древовидную иерархию?—?информационное дерево каталога, и данные, добавляемые в каждый атрибут. Ниже приведён простой пример LDIF-файла, описывающий корневое DN (dc=example, dc=com) и добавляющий одну дочернюю запись в ветку people.

Примечания:

• 1. На данном этапе не так важно досконально разбираться во всех значениях этого LDIF-файла. На данном этапе достаточно знать, что LDIF-файлы могут использоваться для создания DIT и выглядят примерно так, как приведено ниже.
• 2. Добавление LDAP-записей может быть также выполнено с помощью LDAP-клиентов, таких как LDAP-браузеры общего назначения или специализированные приложения.

version: 1.

## указание версии не является строго необходимым (и некоторые реализации его отклоняют),.

## но, в общем случае, это хорошая практика.

## Определяем DIT ROOT/BASE/SUFFIX ####.

## используется формат RFC 2377 (доменные имена).

## dcObject — это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись.

## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization).

# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА.

dn: dc=example, dc=com.

dc: example.

description: Лучшая компания в целом свете.

objectClass: dcObject.

objectClass: organization.

o: Example, Inc.

## ПЕРВЫЙ уровень иерархии — люди (people).

# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой.

dn: ou=people, dc=example, dc=com.

ou: people.

description: Все люди в организации.

objectClass: organizationalUnit.

## ВТОРОЙ уровень иерархии — записи людей.

# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой.

dn: cn=Joe Schmo, ou=people, dc=example, dc=com.

objectclass: inetOrgPerson.

cn: Joe Schmo.

sn: Schmo.

uid: jschmo.

mail: Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script.

mail: Этот адрес e-mail защищен от спам-ботов. Чтобы увидеть его, у Вас должен быть включен Java-Script.

ou: sales.

Важное замечание: Строки в приведённом выше LDIF-файле, начинающиеся с 'dn:', по существу сообщают LDAP-серверу, каким образом структурировать или располагать запись в DIT. В общем случае не важно, значение какого атрибута используется для этой цели, при условии уникальности 'dn:'. В последней записи приведённого примера для этой цели было выбрано cn=Joe Schmo. Точно также могло быть выбрано, скажем, uid=jschmo. При LDAP-поиске может применяться любая комбинация атрибутов и запись будет найдена независимо от того, какое значение было использовано в 'dn:' при её создании. Однако, если запись планируется использовать для аутентификации пользователя, скажем, для входа в систему или организации технологии единого входа (Single Sign-On), значение 'dn:' становится чрезвычайно важным и определяет идентификатор входа в систему. Иногда он называется DN принципала (Principal DN), хотя этот термин не используется в определениях стандартов LDAP.

Приведённый выше LDIF определяет следующую структуру (схема 3):

схема 3.

После того, как DIT определён и запущен в работу, в дальнейшем информацию в него можно добавлять с помощью LDIF, LDAP-браузера, web-интерфейса или другого программного интерфейса.

Используя LDIF-файлы, данные также можно экспортировать в качестве резервной копии или для других целей.

Навигация по дереву

После того, как мы поместили данные в наше дерево, обычно самое время начать с ними работать.

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

Ранее мы определили, что у атрибутов есть имена, и что на каждом уровне иерархии один или несколько атрибутов должны содержать данные, каким-то образом уникально идентифицирующие каждую запись.

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

Такие пути причудливо называются уникальными или отличительными именами (Distinguished Names, DN). Каждый атрибут с уникальными данными, являющийся частью этого DN, называется относительным уникальным именем (Relative Distinguished Name, RDN). Другими словами, DN является суммой всех своих RDN.

Следующая схема 4 иллюстрирует DN и RDN:

схема 4.