4. Установка LDAP

4.1 Установка LDAP
4.2 OpenLDAP на *NIX и Windows
4.3 ApacheDS на *NIX и Windows

5. Примеры конфигураций OpenLDAP

5.1 Простой каталог

5.1.1 Проектирование DIT
5.1.2 Выбор структурного объектного класса
5.1.3 Файл slapd.conf
5.1.4 Файл LDIF
5.1.5 Загрузка LDIF-файла
5.1.6 Добавление записей с помощью LDIF
5.1.7 Изменение записей с помощью LDIF
5.1.8 Напоследок просто подурачимся

5.2 Защита каталога

5.2.1 Политика безопасности
5.2.2 Добавление групп
5.2.3 ACL — директивы access файла slapd.conf
5.2.4 Тестирование ACL

5.3 Расширение иерархии

5.3.1 Расширение требований
5.3.2 Реализация расширения
5.3.3 LDIF для реализации расширения
5.3.4 ACL — директивы access файла slapd.conf
5.3.5 Тестирование ACL

5.4 Создание и добавление объектов

5.4.1 Требования
5.4.2 Реализация
5.4.3 Определения атрибутов
5.4.4 Определение объектного класса и набора схемы
5.4.5 ACL — директивы access файла slapd.conf
5.4.6 LDIF
5.4.7 Тестирование изменений

5.5 Технология единого входа (Single Sign On)
5.6 Отсылки и репликация

6. Конфигурационные файлы

6.1 Обзор slapd.conf
6.1.1 Использование OLC (cn=config)
6.1.1.1 Обзор OLC (cn=config)
6.1.1.2 Переконвертация slapd.conf в OLC (cn=config)
6.1.1.3 Макет OLC (cn=config)
6.1.1.4 Использование OLC (cn=config) (чтение, модификация)
6.1.1.4.1 Общие замечания по конфигурации OLC (cn=config)
6.1.1.4.2 Добавление/удаление наборов схемы данных при использовании OLC (cn=config)
6.1.1.4.3 Добавление/удаление ACP/ACL при использовании OLC (cn=config)
6.1.1.4.4 Добавление/удаление модулей при использовании OLC (cn=config)
6.1.1.4.5 Добавление/удаление баз данных при использовании OLC (cn=config)
6.1.1.4.6 Добавление/удаление наложений при использовании OLC (cn=config)
6.2 Список директив (OLC (cn=config) и slapd.conf)
6.3 Директивы глобального раздела (OLC (cn=config) и slapd.conf)
6.3.1 Директивы TLS (OLC (cn=config) и slapd.conf)
6.4 Директивы раздела backend (OLC (cn=config) и slapd.conf)
6.5 Директивы раздела database (OLC (cn=config) и slapd.conf)
6.5.1 Директивы overlay (OLC (cn=config) и slapd.conf)
6.6 Директивы ldap.conf
6.7 Конфигурация ApacheDS

7. Репликация и отсылки

7.1 Обзор репликации и отсылок
7.2 Репликация
7.2.1 Репликация OpenLDAP
7.2.1.1 Репликация OpenLDAP в стиле slurpd
7.2.1.1.1 Ошибки при репликации OpenLDAP в стиле slurpd
7.2.1.2 Репликация OpenLDAP в стиле syncrepl
7.2.1.2.1 Тип RefreshOnly репликации syncrepl в OpenLDAP
7.2.1.2.2 Тип RefreshAndPersist репликации syncrepl в OpenLDAP
7.2.1.2.3 Репликация syncrepl с несколькими главными серверами (Multi-Master) в OpenLDAP
7.2.1.2.4 Журналы доступа и delta-синхронизация при репликации syncrepl в OpenLDAP
7.2.2 Репликация ApacheDS
7.3 Синхронизация DIT перед запуском репликации в стиле slurpd
7.3 Синхронизация DIT перед запуском репликации в стиле syncrepl
7.4 Отсылки
7.4.1 Сцепление при отсылках

8. LDIF и DSML

8.1 Обзор LDIF
8.2 Формат и директивы LDIF

8.2.1 Формат файла LDIF

8.2.1.1 Терминология LDIF и типы строк
8.2.1.2 Пример LDIF

8.2.2 Директивы LDIF

8.2.2.1 Директива add
8.2.2.2 Директива attributename
8.2.2.3 Директива changetype
8.2.2.4 Директива control
8.2.2.5 Директива delete
8.2.2.6 Директива deleteoldrdn
8.2.2.7 Директива dn
8.2.2.8 Директива newrdn
8.2.2.9 Директива newsuperior
8.2.2.10 Директива objectclass
8.2.2.11 Директива replace
8.2.2.12 Директива version

8.3 Обработка двоичных данных (включая пароли) в LDIF
8.4 Импорт файлов LDIF
8.5 Примеры LDIF
8.6 DSML

9. Функциональная модель LDAP

9.4 LDAP URL

10. LDAP API

11. OpenLDAP HowTo

Конфигурирование нескольких DIT в OpenLDAP
Настройка отсылок в OpenLDAP
Настройка сцепления при отсылках в OpenLDAP
Настройка репликации в стиле slurpd в OpenLDAP
Настройка репликации в стиле syncrepl в OpenLDAP
Настройка delta-синхронизации (syncrepl) в OpenLDAP
Настройка и использование cn=config в OpenLDAP
Замечания по запуску/установке OpenLDAP
Замечания о наложениях в OpenLDAP (или как заставить это работать)
Переход к OLC (cn=config) в OpenLDAP
Использование OLC (cn=config)
Конфигурирование групп пользователей в OpenLDAP

12. Ошибки и устранение неисправностей OpenLDAP

13. Производительность OpenLDAP

14. Инструменты LDAP

Инструменты OpenLDAP

ldapadd — добавление LDIF-записи в каталог LDAP
ldapauth — добавление LDIF-записи в каталог LDAP
ldapdelete — удаление LDAP-записи
ldapmodify — модификация существующих записей LDAP
ldapmodrdn — модификация DN записи LDAP
ldappasswd — модификация пароля записи
ldapsearch — поиск записей LDAP
ldapwhoami — выполнение LDAP-операции Who Am I на сервере
slapacl — проверка доступа к атрибутам путём изучения конфигурации DIT
slapadd — добавление записи LDAP в базу данных
slapauth — проверка данных SASL на соответствие с DIT
slapcat — экспорт LDIF из базы данных LDAP
slapdn — проверка DN на соответствие конфигурации DIT
slapindex — переиндексация базы данных LDAP
slappasswd — генерация пароля
slaptest — проверка файла slapd.conf или директории cn=config (slapd.d)

LDAP-браузеры

LDAPBrowser/Editor — некоторые заметки по использованию

Инструменты ApacheDS

Инструменты ApacheDS — инструменты и утилиты

Список доработок — что ещё нужно сделать

Журнал изменений

Приложение A: Заметки и пояснения к LDAP
Приложение B: Ресурсы LDAP
Приложение C: LDAP RFC и документация
Приложение D: Глоссарий LDAP
Приложение E: Распростанённые наборы схемы данных, объектные классы и атрибуты LDAP

Запись самого верхнего уровня в LDAP DIT (Directory Information Tree, информационном дереве каталога) в мире LDAP неоднозначно называется корневой (root), базовой (base) или суффиксом (suffix), в зависимости от документации, её автора, дня недели или каких-либо других переменных величин, доподлинно нам не известных.

Термин Root DSE определяет своего рода супер-корневую запись (суффикс), содержащую определения всех DIT, поддерживаемых сервером LDAP (в операционном атрибуте namingContexts), а также другие операционные объекты.

Существует несколько методов определения корневой записи или суффикса.

На этой странице описывается метод, основанный на ou. Он самый простой (и, обычно, самый короткий), и, в то же время, удовлетворяющий всем требуемым критериям.

Данное определение будет использовать структурный объектный класс organizationalUnit, у которого всего один обязательный атрибут ou (organizationalUnitName). Фрагмент LDIF для добавления корневой записи или суффикса:

## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX ####
## используется простой формат ou
## замените имя root на любой подходящий текст
## типа my, gobbledegook, suffix, что-либо ещё

## organizationalUnit - это СТРУКТУРНЫЙ объектный класс
#  требующий только наличия атрибута ou (organizationalUnitName)
# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА

dn: ou=root
ou: root
objectclass: organizationalUnit
description: Необязательное описание. Определение тривиальной корневой записи или суффикса. В эту строку можно поместить столько текста, сколько хотите
 в этой строке продолжение информации из предыдущей строки вплоть до 32Kb 
 строка оканчивается либо на <CR>, либо на <CR><LF>, то есть отрабатывается ENTER
 с систем как Windows, так и *nix - новая строка ДОЛЖНА начинаться с ОДНОГО ПРОБЕЛА

Если в OpenLDAP используется динамическая конфигурация OLC (cn=config), следует указать ou=root в качестве значения атрибута olcSuffix записи olcDatabase. При использовании конфигурационного файла slapd.conf, нужно указать suffix "ou=root" в разделе database.

В файле server.xml ApacheDS нужно указать suffix="ou=root" в разделе <partitions><jdbmPartition ...>.

Добавление последующих записей показано в данном фрагменте LDIF:

## ПЕРВЫЙ уровень иерархии - люди (people) 
## для объектных классов используется смешанная форма записи в верхнем и нижнем регистре
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: ou=people, ou=root
ou: people
description: All people in organisation
objectclass: organizationalunit

## ВТОРОЙ уровень иерархии
## ДОБАВЛЯЕМ одну запись в ПЕРВЫЙ уровень (people)
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой
# ou: Human Resources - это название подразделения

dn: cn=Robert Smith,ou=people,ou=root
objectclass: inetOrgPerson
cn: Robert Smith
cn: Robert J Smith
cn: bob  smith
sn: smith
uid: rjsmith
userpassword: rJsmitH
carlicense: HISCAR 123

Запись самого верхнего уровня в LDAP DIT (Directory Information Tree, информационном дереве каталога) в мире LDAP неоднозначно называется корневой (root), базовой (base) или суффиксом (suffix), в зависимости от документации, её автора, дня недели или каких-либо других переменных величин, доподлинно нам не известных.

Термин Root DSE определяет своего рода супер-корневую запись (суффикс), содержащую определения всех DIT, поддерживаемых сервером LDAP (в операционном атрибуте namingContexts), а также другие операционные объекты.

Существует несколько методов определения корневой записи, или суффикса.

На этой странице описывается метод, основанный на RFC 2247 (доменных именах). В дальнейших рассуждениях подразумевается, что доменное имя рассматриваемой организации — example.net, трансформирующееся в корневой DN (базовый DN или суффикс) dc=example, dc= net.

В RFC определено два разных подхода реализации данного метода. Один из них использует структурный объектный класс domain. Однако, гораздо более широкое распространение получил подход с использованием вспомогательного объектного класса dcObject совместно со структурным объектным классом organization, имеющим всего один обязательный атрибут o (organizationName), хотя с тем же успехом можно использовать структурный объектный класс organizationalUnit с обязательным атрибутом ou. Фрагмент LDIF для добавления корневой записи или суффикса:

## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX ####
## используется формат RFC 2247 с объектным классом dcObject
## замените встречающиеся ниже example и net на требуемые компоненты домена

## dcObject - это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись
## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization)
# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА

dn: dc=example,dc=net
dc: example
description: Необязательное описание. Определение корневой записи или суффикса RFC 2247. В эту строку можно поместить столько текста, сколько хотите
 в этой строке продолжение информации из предыдущей строки вплоть до 32Kb 
 строка оканчивается либо на <CR>, либо на <CR><LF>, то есть отрабатывается ENTER
 с систем как Windows, так и *nix - новая строка ДОЛЖНА начинаться с ОДНОГО ПРОБЕЛА
objectClass: dcObject
objectClass: organization
o: Example, Inc.

## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX ####
## используется формат RFC 2247 с объектным классом domain
## замените встречающиеся ниже example и net на требуемые компоненты домена

## domain - это СТРУКТУРНЫЙ объектный класс
# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА

dn: dc=example,dc=net
dc: example
description: Необязательное описание. Определение корневой записи или суффикса RFC 2247. В эту строку можно поместить столько текста, сколько хотите
 в этой строке продолжение информации из предыдущей строки вплоть до 32Kb 
 строка оканчивается либо на <CR>, либо на <CR><LF>, то есть отрабатывается ENTER
 с систем как Windows, так и *nix - новая строка ДОЛЖНА начинаться с ОДНОГО ПРОБЕЛА
objectClass: domain
o: Example, Inc.

Если в OpenLDAP используется динамическая конфигурация OLC (cn=config), следует указать dc=example,dc=net в качестве значения атрибута olcSuffix соответствующей записи olcDatabase. При использовании конфигурационного файла slapd.conf, нужно указать suffix "dc=example,dc=net" в разделе database.

В файле server.xml ApacheDS нужно указать suffix="dc=example,dc=net" в разделе <partitions><jdbmPartition ...>.

Примечания:

1. На первый взгляд это выглядит как значение с несколькими RDN, но на самом деле создаётся одна запись с DN dc=example,dc=net. Большинство серверов LDAP не выполняют проверки того, присутствуют ли значения атрибутов, составляющие DN (RDN), в определении записи.

2. Если в доменном имени несколько меток ccTLD, как, например, в example.net.br, соответственно нужно использовать такой фрагмент:

   ## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX ####
   ## используется формат RFC 2247
   ## замените встречающиеся ниже example и net на требуемые
   ## или, для экспериментов, оставьте как есть
   
   ## dcObject - это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись
   ## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization)
   # это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА
   
   dn: dc=example,dc=net, dc=br
   dc: example
   description: Необязательное описание. Определение корневой записи или суффикса RFC 2247. В эту строку можно поместить столько текста, сколько хотите
    в этой строке продолжение информации из предыдущей строки вплоть до 32Kb 
    строка оканчивается либо на <CR>, либо на <CR><LF>, то есть отрабатывается ENTER
    с систем как Windows, так и *nix - новая строка ДОЛЖНА начинаться с ОДНОГО ПРОБЕЛА
   objectClass: dcObject
   objectClass: organization
   o: Example, S.A.
   

   Соответствующие настройки в olcSuffix (или в slapd.conf) OpenLDAP и server.xml ApacheDS будут suffix "dc=example,dc=net,dc=br".

Расширение DIT

Добавление последующих записей в dc=example,dc=net показано в данном фрагменте LDIF:

## ПЕРВЫЙ уровень иерархии - люди (people) 
## для объектных классов используется смешанная форма записи в верхнем и нижнем регистре
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: ou=people, dc=example,dc=net
ou: people
description: All people in organisation
objectclass: organizationalunit

## ВТОРОЙ уровень иерархии
## ДОБАВЛЯЕМ одну запись в ПЕРВЫЙ уровень (people)
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой
# ou: Human Resources - это название подразделения

dn: cn=Robert Smith,ou=people, dc=example,dc=net
objectclass: inetOrgPerson
cn: Robert Smith
cn: Robert J Smith
cn: bob  smith
sn: smith
uid: rjsmith
userpassword: rJsmitH
carlicense: HISCAR 123

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

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

Плоскость приветствуется

Каталоги в целом обычно имеют очень плоскую структуру, состоящую из двух или трёх уровней иерархии — большее количество встречается редко. Хотя, на первый взгляд, это противоречит интуитивному подходу людей, привыкших работать с классическими базами данных. Вспомните, что LDAP гораздо серьёзней оптимизирован на работу с данными, находящимися НА ОДНОМ УРОВНЕ иерархии, нежели на поиск данных ВВЕРХ и ВНИЗ по иерархии. В этом и кроется суть мощных методов индексирования.

Для иллюстрации достаточно простого примера: когда смотришь на компанию и разрабатываешь структуру каталога, довольно очевидным представляется первоначальное деление по подразделениям компании. НО БУДЕТ ЛИ ЭТО ОПТИМАЛЬНЫМ? Посмотрим на два способа структурирования каталога:

В DIT 1 подразделение представляет собой запись ou, в DIT 2 сведения о подразделении содержатся в атрибуте ou в записях, дочерних к ou=people. Разница кажется тривиальной.

Теперь давайте посмотрим на то, что происходит при некоторых типичных поисковых запросах:

1. Найти всех людей в sales:

   1. DIT 1 — поиск с базовым DN ou=sales,dc=mycompany,dc=com, диапазон — one (один уровень), фильтр cn=*

   2. DIT 2 — поиск с базовым DN ou=people,dc=mycompany,dc=com, диапазон — one (один уровень), фильтр ou=sales

   Практически, одно и то же.

2. Найти всех людей в компании:

   1. DIT 1 — поиск с базовым DN dc=mycompany,dc=com, диапазон — sub (все уровни), фильтр cn=*

   2. DIT 2 — поиск с базовым DN ou=people,dc=mycompany,dc=com, диапазон — one (один уровень), фильтр cn=*

   Структура 2 выигрывает в скорости и простоте.

Лень приветствуется

Придерживаясь принятых нами структур, выполним простую задачу: переведём Билла из sales в marketing (разные подразделения корпорации).

1. DIT 1 — экспортируем запись Билла в файл LDIf, удалим её из sales, отредактируем файл LDIF, добавим запись в marketing. И будем надеяться, что он не будет переводиться слишком часто.

2. DIT 2 — изменим атрибут ou записи Билла с sales на marketing.

Интересно, кто выиграл этот раунд?

olcDbIndex (index)

# форма OLC (cn=config)
olcDbIndex: attrlist | default indices

# форма slapd.conf
index attrlist | default indices

# indices = [pres [,approx] [,eq] [,sub] [,special]]

# Простое использование значения default
# форма OLC (cn=config)
olcDbIndex: default pres,eq
olcDbIndex: cn,sn,uid

# форма slapd.conf
index default pres,eq
index cn,sn,uid

# Определяем индексы наличия и соответствия
# для атрибутов cn, sn и uid
# две приведённые выше директивы index выполняют
# абсолютно то же, что и три, приведённые ниже
index cn pres,eq
index sn pres,eq
index uid pres,eq

index cn eq,sub,subinitial
# Создаём индексы для атрибута cn (commonname)
# для поисков EQUALITY, SUBSTR, а также дальнейшая оптимизация
# для поисков типа sc=a*

index sn eq,approx,sub
# Создаём индексы для атрибута sn (surname)
# для поисков EQUALITY и SUBSTR
# Примечание: Индекс approx index - пустая трата времени,
#     поскольку для sn не определено правило ORDERING,
#     требуемое для поисков approx. Приводится лишь для
#     иллюстрации возможности использования

index mail pres,eq,sub
# Создаём индексы для атрибута mail on
# для поисков на наличие, EQUALITY и SUBSTR

index objectclass eq
# Оптимизируем поиски по форме objectclass=person

Запись самого верхнего уровня в LDAP DIT (Directory Information Tree, информационном дереве каталога) в мире LDAP неоднозначно называется корневой (root), базовой (base) или суффиксом (suffix), в зависимости от документации, её автора, дня недели или каких-либо других переменных величин, доподлинно нам не известных.

Термин Root DSE определяет своего рода супер-корневую запись (суффикс), содержащую определения всех DIT, поддерживаемых сервером LDAP (в операционном атрибуте namingContexts), а также другие операционные объекты.

Существует несколько методов определения корневой записи или суффикса.

На этой странице описывается метод, основанный на подходе X.500. В нём используется ou=name, c=country (хотя никаких формальных стандартов определения корневой записи или суффикса X.500 не существует).

Как нам кажется, самый простой способ — использовать структурный объектный класс organizationalUnit, у которого всего один обязательный атрибут ou (organizationalUnitName), и специальный объектный класс extensibleObject для добавления атрибута c (country). Фрагмент LDIF для добавления корневой записи или суффикса:

## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX ####
## используется формат X.500
## замените example inc. и us любым подходящим текстом

## organizationalUnit - это СТРУКТУРНЫЙ объектный класс
#  требующий только наличия атрибута ou (organizationalUnitName)
#  но не содержащий c (country), который добавляется
#  с помощью extensibleObect
# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА

dn: ou=Example Inc.,c=us
ou: Example Inc.
objectclass: organizationalUnit
description: Необязательное описание. Определение корневой записи или суффикса X.500. В эту строку можно поместить столько текста, сколько хотите
 в этой строке продолжение информации из предыдущей строки вплоть до 32Kb 
 строка оканчивается либо на <CR>, либо на <CR><LF>, то есть отрабатывается ENTER
 с систем как Windows, так и *nix - новая строка ДОЛЖНА начинаться с ОДНОГО ПРОБЕЛА
objectClass: extensibleObject
c: us

Примечания:

1. Строки c: us и objectClass: extensibleObject могут быть исключены из этого фрагмента LDIF, и LDAP продолжит работу как ни в чём не бывало, хотя полнота определения будет потеряна. Большинство серверов LDAP не выполняют проверки того, присутствуют ли значения атрибутов, составляющие DN (RDN), в определении записи.
2. Официально, чтобы соответствовать реальному названию организации, Example Inc. должен записываться как Example, Inc. Если используется такой формат, то запятая, к каком бы месте DN она не встретилась, должна экранироваться следующим образом: Example\, Inc.,c=us, то есть мы вынуждены прикладывать дополнительные усилия без всякой отдачи.

Если в OpenLDAP используется динамическая конфигурация OLC (cn=config), следует указать ou=Example Inc.,c=us в качестве значения атрибута olcSuffix соответствующей записи olcDatabase. При использовании конфигурационного файла slapd.conf, нужно указать suffix "ou=Example Inc.,c=us" в разделе database.

В файле server.xml ApacheDS нужно указать suffix="ou=Example Inc.,c=us" в разделе <partitions><jdbmPartition ...>.

Добавление последующих записей показано в данном фрагменте LDIF:

## ПЕРВЫЙ уровень иерархии - люди (people) 
## для объектных классов используется смешанная форма записи в верхнем и нижнем регистре
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: ou=people, ou=Example Inc.,c=us
ou: people
description: All people in organisation
objectclass: organizationalunit

## ВТОРОЙ уровень иерархии
## ДОБАВЛЯЕМ одну запись в ПЕРВЫЙ уровень (people)
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой
# ou: Human Resources - это название подразделения

dn: cn=Robert Smith,ou=people, ou=Example Inc.,c=us
objectclass: inetOrgPerson
cn: Robert Smith
cn: Robert J Smith
cn: bob  smith
sn: smith
uid: rjsmith
userpassword: rJsmitH
carlicense: HISCAR 123

В приведённых ниже заметках раскрываются подробности о некоторых аспектах LDAP и OpenLDAP:

1. LDAP: Головная боль с именованием корневой записи (базовой записи или суффикса)
2. LDAP: Определение простой корневой записи или суффикса
3. LDAP: Определение корневой записи или суффикса в формате X.500
4. LDAP: Определение корневой записи или суффикса в формате RFC 2247
5. LDAP: Поиск по URL
6. LDAP: DN и RDN
7. LDAP: Подзаписи (subentries)
8. LDAP: DN для аутентификации (DN подключения (Bind DN) и DN принципала (Principal DN))
9. LDAP: Текстовые поисковые фильтры
10. LDAP: Поисковые фильтры соответствия компонентов
11. OpenLDAP: Несколько DIT
12. LDAP: OID (Object Identifiers, идентификаторы объектов)
13. LDAP: Краткое введение в ASN.1
14. LDAP: Руководство по выживанию в ASN.1
15. LDAP: Нужно ли определять иерархию объектных классов?
16. LDAP: Наследование — или как может случиться так, что у записи два или более структурных объектных класса
17. LDAP: Типы данных
18. OpenLDAP: Индексирование записей
19. LDAP: Информация о сравнении и поиске
20. OpenLDAP: Добавление записей — slapadd vs ldapadd
21. LDAP: Некоторые размышления по структурированию каталогов
22. OpenLDAP: Что можно, а что нельзя сделать, без того, чтобы рушить каталог и запускать его заново
23. OpenLDAP: Аргументы командной строки slapd
24. OpenLDAP: Заметки о наложениях в OpenLDAP (или как заставить это работать)
25. LDAP: Определение поисковых фильтров
26. OpenLDAP: Заметки о запуске/инициализации OpenLDAP

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

Примечание: Во многих документах утверждается, что в LDIF-файлах, описывающих DIT и его записи, должна указываться полная иерархия объектных классов, как показано в первой части приведённого ниже фрагмента LDIF. Но есть и другой подход, поддерживаемый большинством современных LDAP-серверов, при котором требуется указать только объектный класс самого последнего уровня в иерархии (содержащий атрибуты, которые будут использоваться); этот подход показан во втором фрагменте LDIF, который функционально идентичен первому фрагменту (есть некоторый побочный эффект от использования данной структуры):

# явное определение всех объектных классов, используемых в записи
dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: jimbob@example.com
ou: sales
title: super hero
...

# В большинстве современных LDAP-систем достаточно определить только
# объектный класс самого последнего уровня иерархии, используемый в записи
dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: jimbob@example.com
ou: sales
title: super hero
...

Все объектные классы person, organizationalPerson и inetOrgPerson являются структурными (в первом фрагменте все указаны явно, во втором первые два неявно подразумеваются). Кажется, правило о том, что запись может содержать только один объектный класс структурного типа, нарушено.

Но это не так.

Объектные классы могут быть частью иерархии, что указывается в определении объектного класса с помощью параметра SUP с именем вышестоящего объектного класса, отличного от top. Когда объектные классы определяются таким способом, каждый дочерний объектный класс ДОЛЖЕН быть того же типа (STRUCTURAL или AUXILLIARY), что и его вышестоящий (родительский) объектный класс. Кроме того, он наследует все атрибуты своего родителя (родителей). В приведённом выше фрагменте LDIF мы просто имеем иерархию структурных объектных классов. Для иллюстрации, объектный класс organizationalPerson содержит атрибут title. Однако, когда мы указываем в записи объектный класс inetOrgPerson, в определении которого присутствует SUP organizationalPerson, то есть organizationalPerson является родительским по отношению к inetOrgPerson, мы можем использовать атрибут title (даже если указывается только один inetOrgPerson, как во втором фрагменте LDIF выше). Мы унаследовали title (как и все остальные атрибуты) от родительского объектного класса. В свою очередь, в определении organizationalPerson есть указание SUP person, таким образом, мы можем использовать любые атрибуты, присутствующие в определении объектного класса person.

Множественное наследование

LDAP не может поддерживать множественное наследование в полном смысле этого слова. Однако, в особых условиях, объектные классы могут иметь в определениях несколько имён вышестоящих (SUP) объектных классов и могут наследовать свойства от нескольких родителей:

# Из RFC 1274
objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'
  SUP ( organization $ organizationalUnit ) STRUCTURAL
  MAY buildingName )

В определении pilotOrganization указано два вышестоящих объектных класса: organization и organizationUnit, и оба они являются структурными. Теперь у нас действительно нарушается правило единственного структурного объектного класса в записи? Не совсем. Посмотрим немного поглубже на то, как определяются объектные классы. Вот ASN.1-определение pilotOrganization:

    pilotOrganization OBJECT-CLASS
        SUBCLASS OF organization, organizationalUnit
        MAY CONTAIN {
                    buildingName}
    ::= {pilotObjectClass 20}

Данное ASN.1-определение говорит о том, что pilotOrganization является подклассом (SUBCLASS OF) сразу и oganization, и organizationalUnit. Теперь посмотрим на ASN.1-определения organization и oganizationalUnit:

   organizationalUnit OBJECT-CLASS
         SUBCLASS OF top
         MUST CONTAIN {
             organizationalUnitName}
         MAY CONTAIN {
             organizationalAttributeSet}
     ::= {objectClass 5}

    organization OBJECT-CLASS
         SUBCLASS OF top
         MUST CONTAIN {
             organizationName}
         MAY CONTAIN {
             organizationalAttributeSet}
     ::= {objectClass 4}

Оба они являются подклассом (SUBCLASS OF) top, то есть они представляют собой самый верхний уровень своих иерархий. Таким образом, если в определении OBJECT-CLASS указано несколько родителей, то допустимо использовать множественное наследование, в ином случае — нет. Почти не существует определений OBJECT-CLASS, предоставляющих такую возможность — кроме pilotOganization мы не нашли ни одного.

Примечание: RFC 1274, определяющее pilotOrganization, стало устаревшим с выходом RFC 4524, и приведённых выше определений ASN.1 в этом RFC больше нет. Однако, файл cosine.schema (OpenLDAP 2.4.11) всё ещё содержит pilotOrganization.

Использование иерархии объектных классов LDAP

На практике, OpenLDAP версий 2.x+ способен обработать иерархию объектных классов, таким образом, следующий фрагмент LDIF, который функционально идентичен первому фрагменту LDIF на этой странице, будет прекрасно работать (и, возможно, немного меньше смущать):

dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: jimbob@example.com
ou: sales
....

Внимание: Если Вы экспортируете данное определение из OpenLDAP, на выходе будет именно то, что Вы указали в LDIF, с помощью которого записи были созданы. Не все серверы LDAP способны автоматически обработать иерархию объектных классов. Если затем Вы попытаетесь загрузить экспортированный LDIF в LDAP-сервер, не способный обработать иерархию объектных классов, скорее всего Вы не получите желаемого результата. Если Вы используете только серверы с поддержкой обработки иерархии (например, только OpenLDAP), то можно сэкономить время, не печатая лишнего.

OID (Object Identifier, идентификатор объекта) — это глобально уникальный номер, идентифицирующий объекты. Глобально-уникальный означает, что во всей вселенной существует единственная организация, отвечающая за определение объекта и его функциональность. Такой организацией может быть международная группа стандартизации, национальная организация или частное предприятие (смотрите обсуждение ниже). Следующее за номером определение OID содержит информацию, состоящую из двух частей: текстового описания и некоторого кода в синтаксисе ASN.1, представляющего собой формальное определение объекта.

OID определяются в Abstract Syntax Notaion One (ASN.1), разработанной ITU-T.

В LDAP (X.500) OID используются для идентификации объектных классов, атрибутов, синтаксисов (типов данных), правил соответствия, механизмов протокола, элементов управления (controls), расширенных операций (extended operations) и поддерживаемых возможностей (supported features).

OID представляет собой структурированный в виде дерева ряд чисел, разделённых точкой, читаемый СЛЕВА НАПРАВО. Примеры OID:

2.5.6 # OID объектных классов x.500
2.5.6.2 # OID объектного класса country
1.3.6.1.4.1.1446 # Critical Angle — используется во многих определениях LDAP
1.3.6.1.4.1.311 # OID корпорации microsoft
1.2.840.113556 # OID американского подразделения корпорации microsoft
2.16.840.1.113730 # Netscape — используется во многих определениях LDAP

Дерево OID организовано СЛЕВА НАПРАВО, таким образом самое левое число означает самый верхний уровень в иерархии и указывает на международную организацию, ответственную за делегирование полномочий по назначению следующих в этом ряду чисел. Самый верхний уровень может быть одним из следующих чисел:

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

OID 2.5.x

Базовый OID 2.5 был назначен itu-iso (смотрите таблицу выше) группе изучения X.500; таким образом, номера, начинающиеся с 2.5, например, 2.5.6.x или 2.5.4.x, выделяются (и определяются) этой группой стандартизации.

OID 1.3.6.1.4.1.x

Базовый OID 1.3.6.1.4.1 — это последовательность номеров частного предприятия Интернет, назначаемых IANA. Любая организация может подать заявку на номер предприятия. Значения СПРАВА от данного полученного номера могут затем использоваться по своему усмотрению. Эти номера могут быть записаны в виде iso.org.dod.internet.private.enterprise, где числа заменены именами, имеющими больше смысла. Трансляция чисел в имена определена в RFC 2578 - 2580.

OID 1.3.6.1.4.1.4203 выделен для OpenLDAP. Многие из используемых OpenLDAP OID имеют форму 1.3.6.1.4.1.1446, которую некоторые считают исторической и взятой из оригинальных спецификаций LDAP, ещё до создания организации OpenLDAP. Просто какой-то детективный роман.

Если есть потребность создать новые объектные классы или атрибуты, обычно прибегают к получению номера частного предприятия от IANA. Повторно использовать уже существующие OID или инвертировать номера — очень скверная штука (Very Bad Thing™), однажды это может Вам аукнуться.

OID используются рядом протоколов IETF, включая SNMP. Не существует установленных правил ассоциации OID с какими-либо пространствами имён; но мы предполагаем, что первая цифра после номера предприятия (arc) используется для идентификации протокола, а следующие ассоциируются с объектами этого протокола, например:

# в строках ниже X — это выданный IANA номер частного предприятия
1.3.6.1.4.1.X.1 — назначается объектам SNMP
1.3.6.1.4.1.X.2 — назначается объектам LDAP
1.3.6.1.4.1.X.2.1 — назначается синтаксисам LDAP
1.3.6.1.4.1.X.2.2 — назначается правилам соответствия LDAP
1.3.6.1.4.1.X.2.3 — назначается атрибутам LDAP
1.3.6.1.4.1.X.2.4 — назначается объектным классам LDAP
1.3.6.1.4.1.X.2.5 — назначается поддерживаемым возможностям LDAP
1.3.6.1.4.1.X.2.9 — назначается механизмам протокола LDAP
1.3.6.1.4.1.X.2.10 — назначается элементам управления LDAP
1.3.6.1.4.1.X.2.11 — назначается расширенным операциям LDAP

И хотя многие из вышеперечисленных категорий могут никогда не быть использованы — думайте масштабно!

OID 1.2.840.x и 2.16.840.x

В базовом OID 1.2.840 iso (1) выделила номер 2 разделу стран-членов (member-country), а следующий за ним номер 840 — США. В этом пространстве можно выделять номера для национальных организаций этой страны (в данном случае США).

Базовый OID 2.16.840 — это вариант выделения пространства для стран от объединения iso-itu (2). Здесь 16 — это страны, а 840 — США.

Порядок назначения OID и их ассоциацию с определениями объектов можно идентифицировать с помощью этого замечательного сайта. Примечание: во многих OID на этом сайте есть ссылка на дополнительную информацию на сайте oid.elibel.tm.fr, который, судя по всему, был заброшен, а затем перевоплотился в www.oid-info.com. Чтобы получить правильную ссылку, просто замените в URL, начинающимся с oid.elibel.tm.fr, данную строку на www.oid-info.com/get, и удалите .html в конце этого URL. Другой способ, — возможно, более быстрый, — выполнить поиск на странице базового поиска (по приведённой выше ссылке).

DN (Distinguished Name, уникальное имя) должно быть уникальным (или хотя бы приблизительно уникальным, смотрите комментарии ниже) в пределах дерева (DIT). В DN описывается содержимое атрибутов в дереве (так называемый путь навигации), требуемое для доступа к конкретной записи ИЛИ базовой (стартовой) записи поиска.

DN состоит из серии RDN (Relative Distinguished Names, относительных уникальных имён), определяемых путём перемещения ВВЕРХ по дереву (DIT) в направлении его корневой записи (суффикса или базовой записи), и записываемых СЛЕВА НАПРАВО, в отличие, например, от файловой системы, где пути записываются СПРАВА НАЛЕВО. Если проводить аналогии, то это больше напоминает полностью определённые доменные имена (fully qualified domain name, FQDN). Если Вы не знаете, что такое полностью определённые доменные имена — забудьте об аналогиях!

DN записывается СЛЕВА НАПРАВО.

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

1. Если мы производим поиск, термин "уникальный" может означать не совсем то, что нам требуется — нам может понадобиться лишь приблизительно уникальный DN.

2. Если мы производим запись (модификацию), тогда DN должен быть уникальным — ведь мы хотим изменять только конкретную запись.

DN состоит из серии RDN (Relative Distinguished Names, относительных уникальных имён), которые представляют собой уникальные (или хотя бы приблизительно уникальные) атрибуты на каждом уровне иерархии DIT.

На рисунке показано построение DN из RDN:

В этом примере в качестве нашего RDN мы выбрали атрибут cn (commonName), поскольку он уникален на данном уровне иерархии в каталоге. Это дало такой полный DN:

DN: cn=Robert Smith,ou=people,dc=example,dc=com

НО мы с тем же успехом могли выбрать в качестве нашего RDN атрибут uid (userID), поскольку он также уникален (смотрите ниже). В обоих случаях в результате получаются вполне допустимые DN.

В атрибутах, используемых в качестве RDN нет ничего особенного, за исключением того, что их значения уникальны (для записи), и должны всегда оставаться уникальными. Но останется ли уникальным наш атрибут cn, когда на работу в организацию устроится второй Robert Smith? Если он не будет уникальным, то эта ситуация останется приемлемой для поиска (чтения), но не для записи — в этом случае нужно будет использовать какой-то другой атрибут или комбинацию атрибутов.

Примечание: Когда запись добавляется (или создаётся), ей всегда назначается DN и, как правило, именно этот DN чаще всего используется для получения доступа к записи. Если данная запись будет использоваться в целях прохождения аутентификации, то на неё накладываются некоторые специальные условия.

Наконец, существует возможность объединить два или более атрибута и сформировать многозначный RDN, который затем будет использоваться в DN. В нашем примере можно сформировать RDN, объединив cn+uid, для создания такого DN:

DN: cn=Robert Smith+uid=rsmith,ou=people,dc=example,dc=com

Примечание: Как правило, если Вы будете часто производить поиск по какому-либо атрибуту, он должен быть проиндексирован.

В этой заметке обсуждаются два метода создания каталога или добавления записей в OpenLDAP — с помощью slapadd и ldapadd.

Уже совсем скоро (One day real soon now™).

Один сервер LDAP может поддерживать одно или несколько DIT.

Каждое DIT является полностью отдельным и имеет свой собственный контекст именования (или пространство имён).

Вот иллюстрация такой конфигурации:

В случае с OpenLDAP каждое DIT и его суффикс (он же корневая или базовая запись), например dc=mydomain.dc=com и dc=mydomain,dc=net, определяется в отдельном разделе database файла slapd.conf.

HOWTO по конфигурации нескольких DIT здесь.

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

Сравнения строк

При сравнении строк типа DirectoryString, IA5String, PrintableString используются следующие правила:

1. Начальные и конечные пробельные символы удаляются.

2. При наличии нескольких пробельных символов подряд они заменяются одним пробелом.

3. При поиске с использованием формы ~= у атрибута, по которому происходит сравнение, требуется наличие индекса approx.

4. При поиске с использованием форм <= или >= у атрибута, по которому происходит сравнение, требуется наличие правила ORDERING. У большинства атрибутов оно не определено.

Во многих документах утверждается, что в LDIF-файлах, описывающих DIT и его записи, должна указываться полная иерархия объектных классов, как показано в этом фрагменте LDIF:

dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: jimbob@example.com
ou: sales
....

Определение объектного класса включает в себя иерархию объектных классов, то есть вышестоящие (SUP) по отношению к нему объектные классы. Все наборы схемы, в которых содержатся ВСЕ объектные классы, составляющие иерархию, должны быть известны серверу LDAP (в OpenLDAP это делается с помощью директив include файла slapd.conf). Таким образом, в теории, сервер LDAP способен самостоятельно поднять иерархию объектных классов, и сделать это намного быстрее, чем Вы её напечатаете. Приведенное выше определение может также внести путаницу видимостью того, что в записи присутствует более одного структурного объектного класса — смотрите дополнительные замечания относительно наследования объектных классов.

На практике, OpenLDAP версий 2.x+ способен обработать иерархию объектных классов, таким образом оба фрагмента LDIF (выше и ниже) будут прекрасно работать, в том числе будет возможность доступа к объектным классам и атрибутам из вышестоящей иерархии. Например, будет доступен атрибут street объектного класса organizationalPerson.

dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: jimbob@example.com
ou: sales
....

Внимание: Если Вы экспортируете последнее определение из OpenLDAP, на выходе будет именно то, что Вы указали в LDIF, с помощью которого записи были созданы. Не все серверы LDAP способны автоматически обработать иерархию объектных классов. Если Вы затем попытаетесь загрузить экспортированный LDIF в LDAP-сервер, не способный обработать иерархию объектных классов, скорее всего Вы не получите желаемого результата. Если Вы используете только серверы с поддержкой обработки иерархии (например, только OpenLDAP), то можно сэкономить время, не печатая лишнего.

В DN описывается содержимое атрибутов в дереве (так называемый путь навигации), требуемое для доступа к конкретной записи ИЛИ базовой (стартовой) записи поиска.

DN состоит из серии RDN (Relative Distinguished Names, относительных уникальных имён), определяемых путём перемещения ВВЕРХ по дереву (DIT) в направлении его корневой записи (суффикса или базовой записи), и записываемых СЛЕВА НАПРАВО, в отличие, например, от файловой системы, где пути записываются СПРАВА НАЛЕВО.

DN записывается СЛЕВА НАПРАВО.

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

version: 1

## нет строгого требования указывать версию (version),
## но это является хорошим тоном для совместимости с будущими версиями

## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX ####
## используется формат RFC 2377

## dcObject - это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись
## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization)
# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА

dn: dc=example,dc=com
dc: example
description: The best company in the whole world
objectClass: dcObject
objectClass: organization
o: Example, Inc.

## ПЕРВЫЙ уровень иерархии - люди (people) 
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: ou=people, dc=example,dc=com
ou: people
description: All people in organisation
objectClass: organizationalUnit

## ВТОРОЙ уровень иерархии - записи людей
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: cn=Joe Schmo,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Joe Schmo
sn: Schmo
uid: jschmo
mail: joe@example.com
mail: j.schmo@example.com
ou: sales

Этот LDIF создаёт следующую структуру каталога:

Как правило, нет разницы, значение какого атрибута используется при добавлении записи, лишь бы соблюдалось условие уникальности 'dn:'. В последней записи приведённого примера для этой цели было решено использовать cn=Joe Schmo. Точно также можно было бы использовать uid=jschmo. В процессе поиска LDAP может быть использован любой атрибут или комбинация атрибутов, так что записи могут быть найдены независимо от того, какое значение 'dn:' использовалось при их создании. Во избежание излишних операций поиска, в большинстве случаев имеет смысл использовать значение 'dn:', представляющее собой тот DN, который чаще всего будет использоваться для доступа к записи. Таким образом, в предыдущем примере подразумевается, что чаще всего при обращении к каталогу будет использоваться атрибут cn=.

Однако, если какую-то запись планируется использовать для аутентификации пользователя, значение её 'dn:' создания становится чрезвычайно важным и определяет единственно возможный DN входа в систему. Причина этого в том, что проверка подлинности осуществляется с помощью LDAP-операции Bind, которая требует предоставления DN подключения (Bind DN) и, опционально, пароля, при этом никакие операции поиска НЕ разрешены. Таким образом, данный DN подключения МОЖЕТ БЫТЬ ТОЛЬКО тем DN, который использовался при добавлении (создании) записи. Следующий LDIF-файл создаёт dn с использованием атрибута uid, более соответствующего системам аутентификации LDAP:

version: 1

## нет строгого требования указывать версию (version),
## но это является хорошим тоном для совместимости с будущими версиями

## ОПРЕДЕЛЯЕМ DIT ROOT/BASE/SUFFIX ####
## используется формат RFC 2377

## dcObject - это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись
## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization)
# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА

dn: dc=example,dc=com
dc: example
description: The best company in the whole world
objectClass: dcObject
objectClass: organization
o: Example, Inc.

## ПЕРВЫЙ уровень иерархии - люди (people) 
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: ou=people, dc=example,dc=com
ou: people
description: All people in organisation
objectClass: organizationalUnit

## ВТОРОЙ уровень иерархии - записи людей
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: uid=jschmo,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Joe Schmo
sn: Schmo
uid: jschmo
mail: joe@example.com
mail: j.schmo@example.com
ou: sales

Этот LDIF создаёт следующую структуру каталога:

В стандартах LDAP нет специального термина, указывающего на DN, используемый при первоначальном создании записи. Однако иногда, особенно в контексте LDAP, применяемого в Microsoft AD, данный DN 'создания' называется DN принципала (Principal DN), главным образом вследствие использования его в качестве принципала (принципала безопасности) в Kerberos.

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

Что можно сделать

Все перечисленные ниже вещи можно сделать, когда каталог уже запущен в работу. Не нужно рушить каталог и запускать его снова, то есть необязательно иметь все эти вещи с самого начала:

1. Вы можете добавить новые записи — в самом деле! Используйте ldapadd с работающим каталогом, либо slapadd, когда OpenLDAP (slapd) остановлен.

2. Вы можете добавить вспомогательный (AUXILLIARY) объектный класс к существующим записям. Например, Вы можете добавить posixaccount к существующей записи с объектным классом inetorgperson.

3. Вы можете добавить структурный (STRUCTURAL) объектный класс к существующим записям, но ТОЛЬКО в том случае, если запись уже содержит объектный класс, родительский (SUP) по отношению к тому, который Вы хотите добавить. Например, Вы можете добавить inetorgperson к существующей записи, в которой присутствует объектный класс person. Но, при тех же условиях, Вы не сможете добавить объектный класс account, поскольку для него родительским классом является top и, таким образом, будет создана вторая иерархия структурных объектных классов, что в настоящий момент строго запрещено.

Чего сделать нельзя

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

Начинаем всё сначала

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

1. Экспортируйте каталог целиком как файл LDIF. Поскольку файлы LDIF — это обыкновенные текстовые файлы, можно написать простенькие скрипты для изменения текста записей каталога в файле, тем самым производя манипуляции с каталогом в целом.

2. Остановите OpenLDAP (slapd). Перейдите в директорию, указанную в разделе database файла slapd.conf, и удалите всё из этой директории.

3. Запустите OpenLDAP (slapd). Используйте ldapadd для импорта Вашего модифицированного файла LDIF обратно в каталог.

Запись самого верхнего уровня в LDAP DIT (Directory Information Tree, информационном дереве каталога) в мире LDAP неоднозначно называется корневой (root), базовой (base) или суффиксом (suffix), в зависимости от документации, её автора, дня недели или каких-либо других переменных величин, доподлинно нам не известных.

Термин Root DSE определяет своего рода супер-корневую запись, содержащую все DIT, поддерживаемые сервером LDAP, а также операционные объекты.

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

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

Ну а теперь — шутки в сторону.

Источник головной боли — изначальная и похвальная цель X.500 (очевидно, имеющая продолжение в IETF): создать глобальную иерархию каталогов, схожую с системой DNS (если эта концепция Вам знакома).

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

Если же у Вас есть (или могут появиться в будущем) глобальные амбиции — читайте далее.

В X.500 в качестве стандарта корневой записи выбран ou=organisation name,c=country code, например, ou=Example Inc., c=u. Какие на то были побудительные мотивы, — непонятно; возможно, в тот момент подобная идея показалась хорошей, а может это связано с фазами Луны. Кое-что об определениях ou. О том, как определить корневую запись или суффикс в формате X.500, читайте здесь.

IETF (в RFC 2247, имеющем, впрочем, только статус информационного) решила использовать для именования корневой записи структуру доменных имён, например, dc=example, dc=com. Отчасти это связано с тем, что подобное именование основано на доменных именах DNS, являющихся по своей природе глобально уникальными, отчасти — по некоторым более специфическим причинам, как то: зная либо SRV-запись DNS, либо имя сервера LDAP, можно сделать предположение о суффиксе каталога. То есть, если имя сервера LDAP (полученное напрямую или через SRV-запись) — ldap.example.com, то разумно будет предположить, что суффикс каталога будет dc=example,dc=com. На наш взгляд, не слишком убедительно. О том, как определить корневую запись или суффикс в формате RFC 2247, читайте здесь.

Если у Вас нет доменного имени — что ж, Вам просто не повезло. Если у Вас несколько доменных имён, Вы вольны выбрать любое (Вы можете даже использовать их все), так как каждое доменное имя уникально.

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

Все три корневые записи на рисунке ниже являются верными. Две из них могут быть глобально уникальными, одна, сами понимаете, нет. Теперь всё!

LDAP поддерживает подмножство (и довольно приличное подмножество) типов данных X.500. Каждый тип данных определяется своим синтаксисом (полный список синтаксисов, поддерживаемых OpenLDAP здесь). Наиболее интересные из них мы рассмотрим подробнее.

При сравнении и поиске атрибутов LDAP выполняет кое-какие классные штуки. Несколько слов об этом здесь.

Содержание

1. Строки
2. Числа (целые числа)
3. Формат времени
4. Телефонные номера
5. Логический тип
6. Двоичный тип
7. Distinguished Name
8. Битовые строки
9. Поддерживаемые синтаксисы LDAP

Строки LDAP

Строки — наиболее распространённый тип данных. Существует целый ряд строковых типов.

1. IA5String (OID=1.3.6.1.4.1.1466.115.121.1.26). Набор символов IA5 (почти ASCII), 7 бит. НЕ разрешены расширенные символы, такие как é, Ø, å и т.п.

2. DirectoryString (OID=1.3.6.1.4.1.1466.115.121.1.15). ISO-10646 (Unicode) кодировка UTF-8 — кодировочная система с нефиксированным количеством бит на символ. Включает в себя IA5/ASCII в качестве подмножества — кое-что об этом. Поддерживает расширенные символы, такие как é, Ø, å и т.п. Поддерживает правила соответствия caseIgnoreMatch и caseIgnoreSubstringsMatch.

3. PrintableString (OID=1.3.6.1.4.1.1466.115.121.1.44). Строка в кодировке IA5 (почти ASCII), с набором символов, ограниченным представлением p раздела 4.1 RFC 2252. НЕ разрешены расширенные символы, такие как é, Ø, å и т.п. Поддерживает правила соответствия caseIgnoreMatch и caseIgnoreSubstringsMatch.

4. OctetString (OID=1.3.6.1.4.1.1466.115.121.1.40). Рассматривается как набор 8-битных байт в чистом виде. Может быть, а может и не быть пригодна для печати и чтения людьми. Обычно используется для паролей. Поддерживает правила соответствия octetStringMatch и octetStringOrderingMatch.

5. PostalAddress (OID=1.3.6.1.4.1.1466.115.121.1.41). Специальный формат, использующий ISO-10646 (Unicode) кодировку UTF-8 с разделителями '$'. Используется для генерации пригодных для печати меток и другого вывода. НЕ разрешены расширенные символы, такие как é, Ø, å и т.п. Поддерживает правила соответствия caseIgnoreListMatch и caseIgnoreListSubstringsMatch.

6. CountryString (OID=1.3.6.1.4.1.1466.115.121.1.11). Специальное поле, использующее набор символов IA5 (почти ASCII), длина которого ограничена ровно двумя символами, представляющими собой код страны согласно ISO 3166. Если требуется полное название страны, используйте friendlyCountryName. Поддерживает правила соответствия caseIgnoreMatch и caseIgnoreSubstringsMatch.

7. NumericString (OID=1.3.6.1.4.1.1466.115.121.1.36) использует числовое подмножество (представление d раздела 4.1 RFC 2252) набора символов IA5 (почти ASCII). Поддерживает правила соответствия numericStringMatch и numericStringSubstringsMatch.

Числа LDAP

Числовые значения реально хранятся в виде строк, но могут, если в определении атрибута указано правило соответствия ORDERING, позволять выполнять числовые сравнения, то есть 100 > 2. Тип Integer определяет 32-битное значение с учётом знака, и, таким образом, может принимать значения в диапазоне от 2³¹-1 (2,147,483,647) до -2³¹ (2,147,483,648).

1. Integer (OID=1.3.6.1.4.1.1466.115.121.1.27). Поддерживает правила соответствия integerMatch (EQUALITY) и integerOrderingMatch (ORDERING).

Стандартные наборы схемы содержат мало целочисленных атрибутов. Большинство числовых полей используют один из приведённых выше строковых типов, особенно тип NumericString.

Формат времени LDAP

1. GeneralizedTime (OID=1.3.6.1.4.1.1466.115.121.1.24). Поддерживает правила соответствия generalizedTimeMatch и generalizedTimeOrderingMatch.

Телефонные номера LDAP

1. TelephoneNumber (OID=1.3.6.1.4.1.1466.115.121.1.50). Поддерживает правила соответствия telephoneNumberMatch и telephoneNumberSubstringsMatch.

Логический тип LDAP

1. Boolean (OID=1.3.6.1.4.1.1466.115.121.1.7). Поддерживает правило соответствия booleanMatch.

Двоичный тип LDAP

1. Binary (OID=1.3.6.1.4.1.1466.115.121.1.5). Для двоичных атрибутов нет правил соответствия.

Distinguished Name LDAP

1. DN (OID=1.3.6.1.4.1.1466.115.121.1.12). Поддерживает правило соответствия distinguishedNameMatch.

Битовые строки LDAP

1. BitString (OID=1.3.6.1.4.1.1466.115.121.1.6). Поддерживает правило соответствия bitStringMatch.

Поддерживаемые OpenLDAP синтаксисы

В приведённом ниже списке перечислены все синтаксисы, поддерживаемые OpenLDAP. Этот список получен с помощью rootDSE subschema. Для того, чтобы найти определения OID, используйте этот сайт, спасший уже не одну жизнь.

Приведённый ниже список может быть получен с помощью следующей команды:

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "cn=subschema" ldapsyntaxes
# Список атрибутов, которые могут быть перечислены:
# matchingruleuse ldapsyntaxes matchingrules attributetypes
# (всё это - коллекции), а также
# createtimestamp modifytimestamp
# Если Вы используете единственный знак +, Вы получите огромный 
# список всего, что знает LDAP-сервер.

# Subschema
dn: cn=Subschema
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.4 
  DESC 'Audio' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.5 
  DESC 'Binary' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.6 
  DESC 'Bit String' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.7 
  DESC 'Boolean' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.8 
  DESC 'Certificate' X-BINARY-TRANSFER-REQUIRED
  'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.9 
  DESC 'Certificate List' X-BINARY-TRANSFER-REQUIRED
  'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.10
  DESC 'Certificate Pair' X-BINARY-TRANSFER-REQUIRED
  'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.11
  DESC 'Country String' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.12
  DESC 'Distinguished Name' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.15
  DESC 'Directory String' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.22
  DESC 'Facsimile Telephone Number' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.24
  DESC 'Generalized Time' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.26
  DESC 'IA5 String' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.27
  DESC 'Integer' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.28
  DESC 'JPEG' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.34
  DESC 'Name And Optional UID' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.36
  DESC 'Numeric String' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.38
  DESC 'OID' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.39
  DESC 'Other Mailbox' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.40
  DESC 'Octet String' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.41
  DESC 'Postal Address' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.44
  DESC 'Printable String' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.49
  DESC 'Supported Algorithm' X-BINARY-TRANSFER-REQUIRED
  'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.50
  DESC 'Telephone Number' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.52
  DESC 'Telex Number' )
ldapSyntaxes: ( 1.3.6.1.1.1.0.0 DESC 'RFC2307
  NIS Netgroup Triple' )
ldapSyntaxes: ( 1.3.6.1.1.1.0.1
  DESC 'RFC2307 Boot Parameter' )
ldapSyntaxes: ( 1.2.826.0.1.3344810.7.1
  DESC 'Serial Number and Issuer' )

По следующим ссылкам можно найти дополнительную информацию о Open Source программном обеспечении LDAP.

Apache Directory Project

Проект Apache Directory — набор приложений, написанных на Java, состоящий из LDAPv3 сервера (с триггерами, хранимыми процедурами, представлениями и другими возможностями, обычно ассоциирующимися с миром транзакционных баз данных), а также со встроенной поддержкой Kerberos5, протокола изменения пароля (Password Change protocol) и скромных возможностей DNS и DHCP. Поставляется с фиксированным (в настоящее время) механизмом манипуляции данными (JDBM). В проект также входит Apache Directory Studio — Java-клиент (на фреймворке eclipse), оптимизированный для использования с Apache Directory Server. Запускается на различных платформах. Лицензия Apache V 2.0.

389 Directory Server (ранее Fedora Directory Server)

Проект Fedora Directory Server — часть спонсируемого Red Hat проекта разработки Fedora. Написан на C и использует основу кода 10-летней давности (родословная восходит к Michigan University -> Netscape Directory Server -> Rehhat Directory Server-> Fedora Directory Server), и только недавно стал Open Source. Очень амбициозный набор функций — особенно операционные возможности. Использует механизм манипуляции данными BDB (Berkeley Database). В настоящее время только для платформ *nix. GPL.

OpenDS

Проект OpenDS написан на Java. Относительно новый сервер службы каталогов, разработанный под jav.net, и, кажется, в значительной степени под руководством изначально Sun Microsystems (а теперь под нежной опекой Oracle). Очень амбициозный набор функций. Запускается на различных платформах. Common Development and Distribution License (CDDL).

OpenLDAP

Высококачественная эталонная разработка LDAP, изначально основанная на работе Мичиганского университета. Активно разрабатывается и широко внедрена. GPL.

По следующим ссылкам можно найти информацию о реализациях LDAP API и библиотеках для различных языков.

Библиотека динамической загрузки DNS-зон BIND-DLZ. Теперь включена в дистрибутив BIND.

Apache LDAP Studio

Часть проекта Apache Directory Service. LDAP Studio интегрирован с фреймворком Eclipse, для скачивания которого, в зависимости от требуемого набора функций, может уйти пару дней. Как можно догадаться по пакету Eclipse, LDAP Studio написан на Java и поставляется почти со всем, что Вам только может понадобиться, LDAP-браузер — лишь небольшая часть всего пакета Studio. Apache Software License 2.0 (OS-лицензия, одобренная Open Source Initiative).

LDAPExplorerTool

LDAP-браузер — добавление, редактирование, удаление или просмотр записей. Версии для Windows и Linux. Бета-версия (середина 2004), но вполне работоспособен. Нет функции поиска. Лицензия BSD. Хорош для доступа к rootDSE, subschema и т.п.

FusionDirectory

LDAP-браузер — версия только для Linux. Пользовательский интерфейс напоминает проводник/браузер. Похоже, оптимизирован для управления учётными записям пользователей, включая Samba PDC. Написан на PHP. Лицензия GPL V2. Изначально основан на ответвлении от проекта GOsa.

JXPlore

LDAP-браузер, основанный на Java — добавление, редактирование, удаление или просмотр записей. Подарок от CA. Лицензия OSI.

LDAP Browser/Editor

LDAP-браузер, основанный на Java — добавление, редактирование, удаление или просмотр записей. Поддержка LDIF. Версии для Windows и Linux. Не обновлялся с 2001 года, но до сих пор вполне работоспособен. Не Open Source — на ноябрь 2009 г. Argonne Labs (текущее местоположение LDAP Browser/Editor) сделал его доступным через Open Channel Foundation и требует небольшой платы (на сегодняшний день 35 долларов) за копию. Прекрасные поисковые возможности.

phpLDAPadmin

LDAP-браузер, основанный на web — добавление, редактирование, удаление или просмотр записей. Написан на PHP — зрелый и активно развивается. Лицензия GNU. Очень мощный.

По следующим ссылкам можно найти информацию по темам, связанным с LDAP:

BDB — документация по BDB (ранее sleepy cat, сейчас принадлежит Oracle). Вам может это понадобиться в случае выполнения серьёзной настройки производительности.

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

DN: uid=bill,ou=people,dc=smokeyjoe,dc=com

attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.6.2.7 2002/01/09 16:49:09 kurt Exp $
#
# RFC1274: Cosine and Internet X.500 schema
#
# This file contains LDAPv3 schema derived from X.500 COSINE "pilot"
# schema.  As this schema was defined for X.500(89), some
# oddities were introduced in the mapping to LDAPv3.  The
# mappings were based upon: draft-ietf-asid-ldapv3-attributes-03.txt
# (a work in progress)
#
# Note: It seems that the pilot schema evolved beyond what was
# described in RFC1274.  However, this document attempts to describes
# RFC1274 as published. 
#
# Depends on core.schema

attributetype ( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORAddress'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

attributetype ( 0.9.2342.19200300.100.1.4 NAME 'info'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )

attributetype ( 0.9.2342.19200300.100.1.5
	NAME ( 'drink' 'favouriteDrink' )
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

attributetype ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

attributetype ( 0.9.2342.19200300.100.1.7 NAME 'photo'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} )

# 9.3.8.  User Class
#
#  The User Class attribute type specifies a category of computer user.
#  The semantics placed on this attribute are for local interpretation.
#  Examples of current usage od this attribute in academia are
#  undergraduate student, researcher, lecturer, etc.  Note that the
#  organizationalStatus attribute may now often be preferred as it makes
#  no distinction between computer users and others.
#
#    userClass ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-user-class))
#    ::= {pilotAttributeType 8}
#
attributetype ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.9.  Host
#
#  The Host attribute type specifies a host computer.
#
#    host ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-host))
#    ::= {pilotAttributeType 9}
#
attributetype ( 0.9.2342.19200300.100.1.9 NAME 'host'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.10.  Manager
#
#  The Manager attribute type specifies the manager of an object
#  represented by an entry.
#
#    manager ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            distinguishedNameSyntax
#    ::= {pilotAttributeType 10}
#
attributetype ( 0.9.2342.19200300.100.1.10 NAME 'manager'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 9.3.11.  Document Identifier
#
#  The Document Identifier attribute type specifies a unique identifier
#  for a document.
#
#    documentIdentifier ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-document-identifier))
#    ::= {pilotAttributeType 11}
#
attributetype ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.12.  Document Title
#
#  The Document Title attribute type specifies the title of a document.
#
#    documentTitle ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#        (SIZE (1 .. ub-document-title))
#    ::= {pilotAttributeType 12}
#
attributetype ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.13.  Document Version
#
#  The Document Version attribute type specifies the version number of a
#  document.
#
#    documentVersion ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-document-version))
#    ::= {pilotAttributeType 13}
#
attributetype ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.14.  Document Author
#
#  The Document Author attribute type specifies the distinguished name
#  of the author of a document.
#
#    documentAuthor ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            distinguishedNameSyntax
#    ::= {pilotAttributeType 14}
#
attributetype ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 9.3.15.  Document Location
#
#  The Document Location attribute type specifies the location of the
#  document original.
#
#    documentLocation ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-document-location))
#    ::= {pilotAttributeType 15}
#
attributetype ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.16.  Home Telephone Number
#
#  The Home Telephone Number attribute type specifies a home telephone
#  number associated with a person.  Attribute values should follow the
#  agreed format for international telephone numbers: i.e., "+44 71 123
#  4567".
#
#    homeTelephoneNumber ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            telephoneNumberSyntax
#    ::= {pilotAttributeType 20}
#
attributetype ( 0.9.2342.19200300.100.1.20
	NAME ( 'homePhone' 'homeTelephoneNumber' )
	EQUALITY telephoneNumberMatch
	SUBSTR telephoneNumberSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

# 9.3.17.  Secretary
#
#  The Secretary attribute type specifies the secretary of a person.
#  The attribute value for Secretary is a distinguished name.
#
#    secretary ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            distinguishedNameSyntax
#    ::= {pilotAttributeType 21}
#
attributetype ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 9.3.18.  Other Mailbox
#
#  The Other Mailbox attribute type specifies values for electronic
#  mailbox types other than X.400 and rfc822.
#
#    otherMailbox ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            SEQUENCE {
#                    mailboxType PrintableString, -- e.g. Telemail
#                    mailbox IA5String  -- e.g. X378:Joe
#            }
#    ::= {pilotAttributeType 22}
#
attributetype ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 )

# 9.3.22.  DNS ARecord
#
#  The A Record attribute type specifies a type A (Address) DNS resource
#  record [6] [7].
#
#    aRecord ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            DNSRecordSyntax
#    ::= {pilotAttributeType 26}
#
## incorrect syntax?
attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

## missing from RFC1274
## incorrect syntax?
attributetype ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 9.3.23.  MX Record
#
#  The MX Record attribute type specifies a type MX (Mail Exchange) DNS
#  resource record [6] [7].
#
#    mXRecord ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            DNSRecordSyntax
#    ::= {pilotAttributeType 28}
#
## incorrect syntax!!
attributetype ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 9.3.24.  NS Record
#
#  The NS Record attribute type specifies an NS (Name Server) DNS
#  resource record [6] [7].
#
#    nSRecord ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            DNSRecordSyntax
#    ::= {pilotAttributeType 29}
#
## incorrect syntax!!
attributetype ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 9.3.25.  SOA Record
#
#  The SOA Record attribute type specifies a type SOA (Start of
#  Authority) DNS resorce record [6] [7].
#
#    sOARecord ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            DNSRecordSyntax
#    ::= {pilotAttributeType 30}
#
## incorrect syntax!!
attributetype ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 9.3.26.  CNAME Record
#
#  The CNAME Record attribute type specifies a type CNAME (Canonical
#  Name) DNS resource record [6] [7].
#
#    cNAMERecord ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            iA5StringSyntax
#    ::= {pilotAttributeType 31}
#
## incorrect syntax!!
attributetype ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 9.3.28.  Associated Name
#
#  The Associated Name attribute type specifies an entry in the
#  organisational DIT associated with a DNS/NRS domain.  See [3] for
#  more details of usage of this attribute.
#
#    associatedName ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            distinguishedNameSyntax
#    ::= {pilotAttributeType 38}
#
attributetype ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 9.3.29.  Home postal address
#
#  The Home postal address attribute type specifies a home postal
#  address for an object.  This should be limited to up to 6 lines of 30
#  characters each.
#
#    homePostalAddress ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            postalAddress
#            MATCHES FOR EQUALITY
#    ::= {pilotAttributeType 39}
#
attributetype ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
	EQUALITY caseIgnoreListMatch
	SUBSTR caseIgnoreListSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

# 9.3.30.  Personal Title
#
#  The Personal Title attribute type specifies a personal title for a
#  person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev".
#
#    personalTitle ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-personal-title))
#    ::= {pilotAttributeType 40}
#
attributetype ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.31.  Mobile Telephone Number
#
#  The Mobile Telephone Number attribute type specifies a mobile
#  telephone number associated with a person.  Attribute values should
#  follow the agreed format for international telephone numbers: i.e.,
#  "+44 71 123 4567".
#
#    mobileTelephoneNumber ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            telephoneNumberSyntax
#    ::= {pilotAttributeType 41}
#
attributetype ( 0.9.2342.19200300.100.1.41
	NAME ( 'mobile' 'mobileTelephoneNumber' )
	EQUALITY telephoneNumberMatch
	SUBSTR telephoneNumberSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

# 9.3.32.  Pager Telephone Number
#
#  The Pager Telephone Number attribute type specifies a pager telephone
#  number for an object. Attribute values should follow the agreed
#  format for international telephone numbers: i.e., "+44 71 123 4567".
#
#    pagerTelephoneNumber ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            telephoneNumberSyntax
#    ::= {pilotAttributeType 42}
#
attributetype ( 0.9.2342.19200300.100.1.42
	NAME ( 'pager' 'pagerTelephoneNumber' )
	EQUALITY telephoneNumberMatch
	SUBSTR telephoneNumberSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

# 9.3.33.  Friendly Country Name
#
#  The Friendly Country Name attribute type specifies names of countries
#  in human readable format.  The standard attribute country name must
#  be one of the two-letter codes defined in ISO 3166.
#
#    friendlyCountryName ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#    ::= {pilotAttributeType 43}
#
attributetype ( 0.9.2342.19200300.100.1.43
	NAME ( 'co' 'friendlyCountryName' )
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 9.3.34.  Unique Identifier
#
#  The Unique Identifier attribute type specifies a "unique identifier"
#  for an object represented in the Directory.  The domain within which
#  the identifier is unique, and the exact semantics of the identifier,
#  are for local definition.  For a person, this might be an
#  institution-wide payroll number.  For an organisational unit, it
#  might be a department code.
#
#    uniqueIdentifier ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-unique-identifier))
#    ::= {pilotAttributeType 44}
#
attributetype ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.35.  Organisational Status
#
#  The Organisational Status attribute type specifies a category by
#  which a person is often referred to in an organisation.  Examples of
#  usage in academia might include undergraduate student, researcher,
#  lecturer, etc.
#
#  A Directory administrator should probably consider carefully the
#  distinctions between this and the title and userClass attributes.
#
#    organizationalStatus ATTRIBUTE
#            WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-organizational-status))
#    ::= {pilotAttributeType 45}
#
attributetype ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.36.  Janet Mailbox
#
#  The Janet Mailbox attribute type specifies an electronic mailbox
#  attribute following the syntax specified in the Grey Book of the
#  Coloured Book series.  This attribute is intended for the convenience
#  of U.K users unfamiliar with rfc822 and little-endian mail addresses.
#  Entries using this attribute MUST also include an rfc822Mailbox
#  attribute.
#
#    janetMailbox ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreIA5StringSyntax
#            (SIZE (1 .. ub-janet-mailbox))
#    ::= {pilotAttributeType 46}
#
attributetype ( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

# 9.3.37.  Mail Preference Option
#
#  An attribute to allow users to indicate a preference for inclusion of
#  their names on mailing lists (electronic or physical).  The absence
#  of such an attribute should be interpreted as if the attribute was
#  present with value "no-list-inclusion".  This attribute should be
#  interpreted by anyone using the directory to derive mailing lists,
#  and its value respected.
#
#    mailPreferenceOption ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX ENUMERATED {
#                no-list-inclusion(0),
#                any-list-inclusion(1),  -- may be added to any lists
#                professional-list-inclusion(2)
#                                        -- may be added to lists
#                                        -- which the list provider
#                                        -- views as related to the
#                                        -- users professional inter-
#                                        -- ests, perhaps evaluated
#                                        -- from the business of the
#                                        -- organisation or keywords
#                                        -- in the entry.
#                }
#    ::= {pilotAttributeType 47}
#
attributetype ( 0.9.2342.19200300.100.1.47
	NAME 'mailPreferenceOption'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

# 9.3.38.  Building Name
#
#  The Building Name attribute type specifies the name of the building
#  where an organisation or organisational unit is based.
#
#    buildingName ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            caseIgnoreStringSyntax
#            (SIZE (1 .. ub-building-name))
#    ::= {pilotAttributeType 48}
#
attributetype ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

# 9.3.39.  DSA Quality
#
#  The DSA Quality attribute type specifies the purported quality of a
#  DSA.  It allows a DSA manager to indicate the expected level of
#  availability of the DSA. See [8] for details of the syntax.
#
#    dSAQuality ATTRIBUTE
#            WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
#            SINGLE VALUE
#    ::= {pilotAttributeType 49}
#
attributetype ( 0.9.2342.19200300.100.1.49 NAME 'dSAQuality'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.19 SINGLE-VALUE )

# 9.3.40.  Single Level Quality
#
#  The Single Level Quality attribute type specifies the purported data
#  quality at the level immediately below in the DIT.  See [8] for
#  details of the syntax.
#
#    singleLevelQuality ATTRIBUTE
#            WITH ATTRIBUTE-SYNTAX DataQualitySyntax
#            SINGLE VALUE
#    ::= {pilotAttributeType 50}
#
attributetype ( 0.9.2342.19200300.100.1.50 NAME 'singleLevelQuality'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE )

# 9.3.41.  Subtree Minimum Quality
#
#  The Subtree Minimum Quality attribute type specifies the purported
#  minimum data quality for a DIT subtree.  See [8] for more discussion
#  and details of the syntax.
#
#    subtreeMinimumQuality ATTRIBUTE
#            WITH ATTRIBUTE-SYNTAX DataQualitySyntax
#            SINGLE VALUE
#               -- Defaults to singleLevelQuality
#    ::= {pilotAttributeType 51}
#
attributetype ( 0.9.2342.19200300.100.1.51 NAME 'subtreeMinimumQuality'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE )

# 9.3.42.  Subtree Maximum Quality
#
#  The Subtree Maximum Quality attribute type specifies the purported
#  maximum data quality for a DIT subtree.  See [8] for more discussion
#  and details of the syntax.
#
#    subtreeMaximumQuality ATTRIBUTE
#            WITH ATTRIBUTE-SYNTAX DataQualitySyntax
#            SINGLE VALUE
#               -- Defaults to singleLevelQuality
#    ::= {pilotAttributeType 52}
#
attributetype ( 0.9.2342.19200300.100.1.52 NAME 'subtreeMaximumQuality'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE )

# 9.3.43.  Personal Signature
#
#  The Personal Signature attribute type allows for a representation of
#  a person's signature.  This should be encoded in G3 fax as explained
#  in recommendation T.4, with an ASN.1 wrapper to make it compatible
#  with an X.400 BodyPart as defined in X.420.
#
#    IMPORT  G3FacsimileBodyPart  FROM  {   mhs-motis   ipms   modules
#    information-objects }
#
#    personalSignature ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            CHOICE {
#                g3-facsimile [3] G3FacsimileBodyPart
#                }
#        (SIZE (1 .. ub-personal-signature))
#    ::= {pilotAttributeType 53}
#
attributetype ( 0.9.2342.19200300.100.1.53 NAME 'personalSignature'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.23 )

# 9.3.44.  DIT Redirect
#
#  The DIT Redirect attribute type is used to indicate that the object
#  described by one entry now has a newer entry in the DIT.  The entry
#  containing the redirection attribute should be expired after a
#  suitable grace period.  This attribute may be used when an individual
#  changes his/her place of work, and thus acquires a new organisational
#  DN.
#
#    dITRedirect ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            distinguishedNameSyntax
#    ::= {pilotAttributeType 54}
#
attributetype ( 0.9.2342.19200300.100.1.54 NAME 'dITRedirect'
	 EQUALITY distinguishedNameMatch
	 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# 9.3.45.  Audio
#
#  The Audio attribute type allows the storing of sounds in the
#  Directory.  The attribute uses a u-law encoded sound file as used by
#  the "play" utility on a Sun 4.  This is an interim format.
#
#    audio ATTRIBUTE
#        WITH ATTRIBUTE-SYNTAX
#            Audio
#        (SIZE (1 .. ub-audio))
#    ::= {pilotAttributeType 55}
#
attributetype ( 0.9.2342.19200300.100.1.55 NAME 'audio'
	 SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} )

# 9.3.46.  Publisher of Document
#
#
#  The Publisher of Document attribute is the person and/or organization
#  that published a document.
#
#    documentPublisher ATTRIBUTE
#            WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
#    ::= {pilotAttributeType 56}
#
attributetype ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 8.3.2.  Pilot Person
#
#  The PilotPerson object class is used as a sub-class of person, to
#  allow the use of a number of additional attributes to be assigned to
#  entries of object class person.
#
#    pilotPerson OBJECT-CLASS
#        SUBCLASS OF person
#        MAY CONTAIN {
#                    userid,
#                    textEncodedORAddress,
#                    rfc822Mailbox,
#                    favouriteDrink,
#                    roomNumber,
#                    userClass,
#                    homeTelephoneNumber,
#                    homePostalAddress,
#                    secretary,
#                    personalTitle,
#                    preferredDeliveryMethod,
#                    businessCategory,
#                    janetMailbox,
#                    otherMailbox,
#                    mobileTelephoneNumber,
#                    pagerTelephoneNumber,
#                    organizationalStatus,
#                    mailPreferenceOption,
#                    personalSignature}
#    ::= {pilotObjectClass 4}
#
objectclass ( 0.9.2342.19200300.100.4.4
	NAME ( 'pilotPerson' 'newPilotPerson' )
	SUP person STRUCTURAL
	MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $
		favouriteDrink $ roomNumber $ userClass $
		homeTelephoneNumber $ homePostalAddress $ secretary $
		personalTitle $ preferredDeliveryMethod $ businessCategory $
		janetMailbox $ otherMailbox $ mobileTelephoneNumber $
		pagerTelephoneNumber $ organizationalStatus $
		mailPreferenceOption $ personalSignature )
	)

# 8.3.3.  Account
#
#  The Account object class is used to define entries representing
#  computer accounts.  The userid attribute should be used for naming
#  entries of this object class.
#
#    account OBJECT-CLASS
#        SUBCLASS OF top
#        MUST CONTAIN {
#            userid}
#        MAY CONTAIN {
#            description,
#            seeAlso,
#            localityName,
#            organizationName,
#            organizationalUnitName,
#            host}
#    ::= {pilotObjectClass 5}
#
objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account'
	SUP top STRUCTURAL
	MUST userid
	MAY ( description $ seeAlso $ localityName $
		organizationName $ organizationalUnitName $ host )
	)

# 8.3.4.  Document
#
#  The Document object class is used to define entries which represent
#  documents.
#
#    document OBJECT-CLASS
#        SUBCLASS OF top
#        MUST CONTAIN {
#            documentIdentifier}
#        MAY CONTAIN {
#            commonName,
#            description,
#            seeAlso,
#            localityName,
#            organizationName,
#            organizationalUnitName,
#            documentTitle,
#            documentVersion,
#            documentAuthor,
#            documentLocation,
#            documentPublisher}
#    ::= {pilotObjectClass 6}
#
objectclass ( 0.9.2342.19200300.100.4.6 NAME 'document'
	SUP top STRUCTURAL
	MUST documentIdentifier
	MAY ( commonName $ description $ seeAlso $ localityName $
		organizationName $ organizationalUnitName $
		documentTitle $ documentVersion $ documentAuthor $
		documentLocation $ documentPublisher )
	)

# 8.3.5.  Room
#
#  The Room object class is used to define entries representing rooms.
#  The commonName attribute should be used for naming pentries of this
#  object class.
#
#    room OBJECT-CLASS
#        SUBCLASS OF top
#        MUST CONTAIN {
#            commonName}
#        MAY CONTAIN {
#            roomNumber,
#            description,
#            seeAlso,
#            telephoneNumber}
#    ::= {pilotObjectClass 7}
#
objectclass ( 0.9.2342.19200300.100.4.7 NAME 'room'
	SUP top STRUCTURAL
	MUST commonName
	MAY ( roomNumber $ description $ seeAlso $ telephoneNumber )
	)

# 8.3.6.  Document Series
#
#  The Document Series object class is used to define an entry which
#  represents a series of documents (e.g., The Request For Comments
#  papers).
#
#    documentSeries OBJECT-CLASS
#        SUBCLASS OF top
#        MUST CONTAIN {
#            commonName}
#        MAY CONTAIN {
#            description,
#            seeAlso,
#            telephoneNumber,
#            localityName,
#            organizationName,
#            organizationalUnitName}
#    ::= {pilotObjectClass 9}
#
objectclass ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
	SUP top STRUCTURAL
	MUST commonName
	MAY ( description $ seeAlso $ telephonenumber $
		localityName $ organizationName $ organizationalUnitName )
	)

# 8.3.7.  Domain
#
#  The Domain object class is used to define entries which represent DNS
#  or NRS domains.  The domainComponent attribute should be used for
#  naming entries of this object class.  The usage of this object class
#  is described in more detail in [3].
#
#    domain OBJECT-CLASS
#        SUBCLASS OF top
#        MUST CONTAIN {
#            domainComponent}
#        MAY CONTAIN {
#            associatedName,
#            organizationName,
#            organizationalAttributeSet}
#    ::= {pilotObjectClass 13}
#
objectclass ( 0.9.2342.19200300.100.4.13 NAME 'domain'
	SUP top STRUCTURAL
	MUST domainComponent
	MAY ( associatedName $ organizationName $ description $
		businessCategory $ seeAlso $ searchGuide $ userPassword $
		localityName $ stateOrProvinceName $ streetAddress $
		physicalDeliveryOfficeName $ postalAddress $ postalCode $
		postOfficeBox $ streetAddress $
		facsimileTelephoneNumber $ internationalISDNNumber $
		telephoneNumber $ teletexTerminalIdentifier $ telexNumber $
		preferredDeliveryMethod $ destinationIndicator $
		registeredAddress $ x121Address )
	)

# 8.3.8.  RFC822 Local Part
#
#  The RFC822 Local Part object class is used to define entries which
#  represent the local part of RFC822 mail addresses.  This treats this
#  part of an RFC822 address as a domain.  The usage of this object
#  class is described in more detail in [3].
#
#    rFC822localPart OBJECT-CLASS
#        SUBCLASS OF domain
#        MAY CONTAIN {
#            commonName,
#            surname,
#            description,
#            seeAlso,
#            telephoneNumber,
#            postalAttributeSet,
#            telecommunicationAttributeSet}
#    ::= {pilotObjectClass 14}
#
objectclass ( 0.9.2342.19200300.100.4.14 NAME 'RFC822localPart'
	SUP domain STRUCTURAL
	MAY ( commonName $ surname $ description $ seeAlso $ telephonenumber $
		physicalDeliveryOfficeName $ postalAddress $ postalCode $
		postOfficeBox $ streetAddress $
		facsimileTelephoneNumber $ internationalISDNNumber $
		telephoneNumber $ teletexTerminalIdentifier $
		telexNumber $ preferredDeliveryMethod $ destinationIndicator $
		registeredAddress $ x121Address )
	)

# 8.3.9.  DNS Domain
#
#  The DNS Domain (Domain NameServer) object class is used to define
#  entries for DNS domains.  The usage of this object class is described
#  in more detail in [3].
#
#    dNSDomain OBJECT-CLASS
#        SUBCLASS OF domain
#        MAY CONTAIN {
#            ARecord,
#            MDRecord,
#            MXRecord,
#            NSRecord,
#            SOARecord,
#            CNAMERecord}
#    ::= {pilotObjectClass 15}
#
objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain'
	SUP 'domain' STRUCTURAL
	MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ 
		SOARecord $ CNAMERecord )
	)

# 8.3.10.  Domain Related Object
#
#  The Domain Related Object object class is used to define entries
#  which represent DNS/NRS domains which are "equivalent" to an X.500
#  domain: e.g., an organisation or organisational unit.  The usage of
#  this object class is described in more detail in [3].
#
#    domainRelatedObject OBJECT-CLASS
#        SUBCLASS OF top
#        MUST CONTAIN {
#            associatedDomain}
#    ::= {pilotObjectClass 17}
#
objectclass ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
	SUP top AUXILIARY
	MUST associatedDomain )

# 8.3.11.  Friendly Country
#
#  The Friendly Country object class is used to define country entries
#  in the DIT.  The object class is used to allow friendlier naming of
#  countries than that allowed by the object class country.  The naming
#  attribute of object class country, countryName, has to be a 2 letter
#  string defined in ISO 3166.
#
#    friendlyCountry OBJECT-CLASS
#        SUBCLASS OF country
#        MUST CONTAIN {
#            friendlyCountryName}
#    ::= {pilotObjectClass 18}
#
objectclass ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
	SUP country STRUCTURAL
	MUST friendlyCountryName )

# 8.3.13.  Pilot Organization
#
#  The PilotOrganization object class is used as a sub-class of
#  organization and organizationalUnit to allow a number of additional
#  attributes to be assigned to entries of object classes organization
#  and organizationalUnit.
#
#    pilotOrganization OBJECT-CLASS
#        SUBCLASS OF organization, organizationalUnit
#        MAY CONTAIN {
#                    buildingName}
#    ::= {pilotObjectClass 20}
#
objectclass ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'
	SUP ( organization $ organizationalUnit ) STRUCTURAL
	MAY buildingName )

# 8.3.14.  Pilot DSA
#
#  The PilotDSA object class is used as a sub-class of the dsa object
#  class to allow additional attributes to be assigned to entries for
#  DSAs.
#
#    pilotDSA OBJECT-CLASS
#        SUBCLASS OF dsa
#        MUST CONTAIN {
#            dSAQuality}
#    ::= {pilotObjectClass 21}
#
objectclass ( 0.9.2342.19200300.100.4.21 NAME 'pilotDSA'
	SUP dsa STRUCTURAL
	MAY dSAQuality )

# 8.3.15.  Quality Labelled Data
#
#  The Quality Labelled Data object class is used to allow the
#  assignment of the data quality attributes to subtrees in the DIT.
#
#  See [8] for more details.
#
#    qualityLabelledData OBJECT-CLASS
#        SUBCLASS OF top
#        MUST CONTAIN {
#            dSAQuality}
#        MAY CONTAIN {
#            subtreeMinimumQuality,
#            subtreeMaximumQuality}
#    ::= {pilotObjectClass 22}
objectclass ( 0.9.2342.19200300.100.4.22 NAME 'qualityLabelledData'
	SUP top AUXILIARY
	MUST dsaQuality
	MAY ( subtreeMinimumQuality $ subtreeMaximumQuality )
	)

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# $OpenLDAP: pkg/ldap/servers/slapd/schema/ppolicy.schema,v 1.7.2.3 2008/02/11 23:26:49 kurt Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 2004-2008 The OpenLDAP Foundation.
## All rights reserved.
##
## Redistribution and use in source and binary forms, with or without
## modification, are permitted only as authorized by the OpenLDAP
## Public License.
##
## A copy of this license is available in the file LICENSE in the
## top-level directory of the distribution or, alternatively, at
## <http://www.OpenLDAP.org/license.html>.
#
## Portions Copyright (C) The Internet Society (2004).
## Please see full copyright statement below.

# Definitions from Draft behera-ldap-password-policy-07 (a work in progress)
#	Password Policy for LDAP Directories
# With extensions from Hewlett-Packard:
#	pwdCheckModule etc.

# Contents of this file are subject to change (including deletion)
# without notice.
#
# Not recommended for production use!
# Use with extreme caution!

#Network Working Group                                     J. Sermersheim
#Internet-Draft                                               Novell, Inc
#Expires: April 24, 2005                                        L. Poitou
#                                                        Sun Microsystems
#                                                        October 24, 2004
#
#
#                  Password Policy for LDAP Directories
#                draft-behera-ldap-password-policy-08.txt
#
#Status of this Memo
#
#   This document is an Internet-Draft and is subject to all provisions
#   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
#   author represents that any applicable patent or other IPR claims of
#   which he or she is aware have been or will be disclosed, and any of
#   which he or she become aware will be disclosed, in accordance with
#   RFC 3668.
#
#   Internet-Drafts are working documents of the Internet Engineering
#   Task Force (IETF), its areas, and its working groups.  Note that
#   other groups may also distribute working documents as
#   Internet-Drafts.
#
#   Internet-Drafts are draft documents valid for a maximum of six months
#   and may be updated, replaced, or obsoleted by other documents at any
#   time.  It is inappropriate to use Internet-Drafts as reference
#   material or to cite them other than as "work in progress."
#
#   The list of current Internet-Drafts can be accessed at
#   http://www.ietf.org/ietf/1id-abstracts.txt.
#
#   The list of Internet-Draft Shadow Directories can be accessed at
#   http://www.ietf.org/shadow.html.
#
#   This Internet-Draft will expire on April 24, 2005.
#
#Copyright Notice
#
#   Copyright (C) The Internet Society (2004).
#
#Abstract
#
#   Password policy as described in this document is a set of rules that
#   controls how passwords are used and administered in Lightweight
#   Directory Access Protocol (LDAP) based directories.  In order to
#   improve the security of LDAP directories and make it difficult for
#   password cracking programs to break into directories, it is desirable
#   to enforce a set of rules on password usage.  These rules are made to
#
#  [trimmed]
#
#5.  Schema used for Password Policy
#
#   The schema elements defined here fall into two general categories.  A
#   password policy object class is defined which contains a set of
#   administrative password policy attributes, and a set of operational
#   attributes are defined that hold general password policy state
#   information for each user.
#
#5.2  Attribute Types used in the pwdPolicy ObjectClass
#
#   Following are the attribute types used by the pwdPolicy object class.
#
#5.2.1  pwdAttribute
#
#   This holds the name of the attribute to which the password policy is
#   applied.  For example, the password policy may be applied to the
#   userPassword attribute.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.1
      NAME 'pwdAttribute'
      EQUALITY objectIdentifierMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

#5.2.2  pwdMinAge
#
#   This attribute holds the number of seconds that must elapse between
#   modifications to the password.  If this attribute is not present, 0
#   seconds is assumed.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.2
      NAME 'pwdMinAge'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.3  pwdMaxAge
#
#   This attribute holds the number of seconds after which a modified
#   password will expire.
#
#   If this attribute is not present, or if the value is 0 the password
#   does not expire.  If not 0, the value must be greater than or equal
#   to the value of the pwdMinAge.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.3
      NAME 'pwdMaxAge'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.4  pwdInHistory
#
#   This attribute specifies the maximum number of used passwords stored
#   in the pwdHistory attribute.
#
#   If this attribute is not present, or if the value is 0, used
#   passwords are not stored in the pwdHistory attribute and thus may be
#   reused.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.4
      NAME 'pwdInHistory'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.5  pwdCheckQuality
#
#   {TODO: Consider changing the syntax to OID.  Each OID will list a
#   quality rule (like min len, # of special characters, etc).  These
#   rules can be specified outsid ethis document.}
#
#   {TODO: Note that even though this is meant to be a check that happens
#   during password modification, it may also be allowed to happen during
#   authN.  This is useful for situations where the password is encrypted
#   when modified, but decrypted when used to authN.}
#
#   This attribute indicates how the password quality will be verified
#   while being modified or added.  If this attribute is not present, or
#   if the value is '0', quality checking will not be enforced.  A value
#   of '1' indicates that the server will check the quality, and if the
#   server is unable to check it (due to a hashed password or other
#   reasons) it will be accepted.  A value of '2' indicates that the
#   server will check the quality, and if the server is unable to verify
#   it, it will return an error refusing the password.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.5
      NAME 'pwdCheckQuality'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.6  pwdMinLength
#
#   When quality checking is enabled, this attribute holds the minimum
#   number of characters that must be used in a password.  If this
#   attribute is not present, no minimum password length will be
#   enforced.  If the server is unable to check the length (due to a
#   hashed password or otherwise), the server will, depending on the
#   value of the pwdCheckQuality attribute, either accept the password
#   without checking it ('0' or '1') or refuse it ('2').

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.6
      NAME 'pwdMinLength'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.7  pwdExpireWarning
#
#   This attribute specifies the maximum number of seconds before a
#   password is due to expire that expiration warning messages will be
#   returned to an authenticating user.
#
#   If this attribute is not present, or if the value is 0 no warnings
#   will be returned.  If not 0, the value must be smaller than the value
#   of the pwdMaxAge attribute.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.7
      NAME 'pwdExpireWarning'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.8  pwdGraceAuthNLimit
#
#   This attribute specifies the number of times an expired password can
#   be used to authenticate.  If this attribute is not present or if the
#   value is 0, authentication will fail.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.8
      NAME 'pwdGraceAuthNLimit'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.9  pwdLockout
#
#   This attribute indicates, when its value is "TRUE", that the password
#   may not be used to authenticate after a specified number of
#   consecutive failed bind attempts.  The maximum number of consecutive
#   failed bind attempts is specified in pwdMaxFailure.
#
#   If this attribute is not present, or if the value is "FALSE", the
#   password may be used to authenticate when the number of failed bind
#   attempts has been reached.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.9
      NAME 'pwdLockout'
      EQUALITY booleanMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
      SINGLE-VALUE )

#5.2.10  pwdLockoutDuration
#
#   This attribute holds the number of seconds that the password cannot
#   be used to authenticate due to too many failed bind attempts.  If
#   this attribute is not present, or if the value is 0 the password
#   cannot be used to authenticate until reset by a password
#   administrator.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.10
      NAME 'pwdLockoutDuration'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.11  pwdMaxFailure
#
#   This attribute specifies the number of consecutive failed bind
#   attempts after which the password may not be used to authenticate.
#   If this attribute is not present, or if the value is 0, this policy
#   is not checked, and the value of pwdLockout will be ignored.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.11
      NAME 'pwdMaxFailure'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.12  pwdFailureCountInterval
#
#   This attribute holds the number of seconds after which the password
#   failures are purged from the failure counter, even though no
#   successful authentication occurred.
#
#   If this attribute is not present, or if its value is 0, the failure
#   counter is only reset by a successful authentication.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.12
      NAME 'pwdFailureCountInterval'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )

#5.2.13  pwdMustChange
#
#   This attribute specifies with a value of "TRUE" that users must
#   change their passwords when they first bind to the directory after a
#   password is set or reset by a password administrator.  If this
#   attribute is not present, or if the value is "FALSE", users are not
#   required to change their password upon binding after the password
#   administrator sets or resets the password.  This attribute is not set
#   due to any actions specified by this document, it is typically set by
#   a password administrator after resetting a user's password.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.13
      NAME 'pwdMustChange'
      EQUALITY booleanMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
      SINGLE-VALUE )

#5.2.14  pwdAllowUserChange
#
#   This attribute indicates whether users can change their own
#   passwords, although the change operation is still subject to access
#   control.  If this attribute is not present, a value of "TRUE" is
#   assumed.  This attribute is intended to be used in the absense of an
#   access control mechanism.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.14
      NAME 'pwdAllowUserChange'
      EQUALITY booleanMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
      SINGLE-VALUE )

#5.2.15  pwdSafeModify
#
#   This attribute specifies whether or not the existing password must be
#   sent along with the new password when being changed.  If this
#   attribute is not present, a "FALSE" value is assumed.

attributetype ( 1.3.6.1.4.1.42.2.27.8.1.15
      NAME 'pwdSafeModify'
      EQUALITY booleanMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
      SINGLE-VALUE )

# <MODIFIED> Mozilla extension
# 5.2.16  pwdMaxTotalAttempts

# This attribute may take one of three values:
# a. Zero (0) This indicates that repeat password checking is not invoked. 
#   The value 0 is defaulted if the attribute is not present.
# b. A positive number in the range 1 to 65535 defines the maximum number of 
#    failed bind attempts using a repeated password after which any password 
#    may not be used to authenticate. 
# c. -1 (minus 1). This indicates that repeat password detection features are
#    required but an unlimited number of repeat password attempts are allowed.
# When repeat password detection is invoked (pwdMaxTotalAttempts is either -1
# or in the range 1 to 65535) each failed password attempt is evaluated against
# the list maintained in pwdUnigueAttempts and if not present will be added to
# pwdUniqueAttempts and also to pwdFailureTime. Thus the first attempt to use
# any password will count toward the value defined in pwdMaxFailure. If the 
# failed password is present in pwdUniqueAttempts it will only increment the
# appropriate counter in pwdUniqueAttempts if pwdMaxTotalAttempts is in the 
# range 1 to 65535. When the sum of all non-expired counts in pwdUniqueAttempts
# equals pwdMaxTotalAttempts then the action defined by pwdLockout is invoked. 
# If this attribute is not present (defaults to 0), or if the value is 0, no 
# repeat password detection is invoked and any failed password attempt (whether
# repeat or unique) will count toward the value defined by pwdMaxFailure. If 
# the value is set to -1 then an unlimited number of repeat password attempts
# are allowed.

attributetype  ( 1.3.6.1.4.1.13769.1.3.1
      NAME 'pwdMaxTotalAttempts'
      EQUALITY integerMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
      SINGLE-VALUE )
</MODIFIED>


# HP extensions
#
# pwdCheckModule
#
#    This attribute names a user-defined loadable module that provides
#    a check_password() function. If pwdCheckQuality is set to '1' or '2'
#    this function will be called after all of the internal password
#    quality checks have been passed. The function has this prototype:
#
#    int check_password( char *password, char **errormessage, void *arg )
#
#    The function should return LDAP_SUCCESS for a valid password.

attributetype ( 1.3.6.1.4.1.4754.1.99.1
     NAME 'pwdCheckModule'
     EQUALITY caseExactIA5Match
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
     DESC 'Loadable module that instantiates "check_password() function'
     SINGLE-VALUE )

objectclass ( 1.3.6.1.4.1.4754.2.99.1
      NAME 'pwdPolicyChecker'
      SUP top
      AUXILIARY
      MAY ( pwdCheckModule ) )

#5.1  The pwdPolicy Object Class
#
#   This object class contains the attributes defining a password policy
#   in effect for a set of users.  Section 10 describes the
#   administration of this object, and the relationship between it and
#   particular objects.
#
objectclass ( 1.3.6.1.4.1.42.2.27.8.2.1
      NAME 'pwdPolicy'
      SUP top
      AUXILIARY
      MUST ( pwdAttribute )
      MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
      pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout
      $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
      pwdMustChange $ pwdAllowUserChange $ pwdMaxTotalAttempts $ pwdSafeModify ) )

#5.3  Attribute Types for Password Policy State Information
#
#   Password policy state information must be maintained for each user.
#   The information is located in each user entry as a set of operational
#   attributes.  These operational attributes are: pwdChangedTime,
#   pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime,
#   pwdReset, pwdPolicySubEntry.
#
#5.3.1  Password Policy State Attribute Option
#
#   Since the password policy could apply to several attributes used to
#   store passwords, each of the above operational attributes must have
#   an option to specify which pwdAttribute it applies to.  The password
#   policy option is defined as the following:
#
#   pwd-<passwordAttribute>
#
#   where passwordAttribute a string following the OID syntax
#   (1.3.6.1.4.1.1466.115.121.1.38).  The attribute type descriptor
#   (short name) MUST be used.
#
#   For example, if the pwdPolicy object has for pwdAttribute
#   "userPassword" then the pwdChangedTime operational attribute, in a
#   user entry, will be:
#
#   pwdChangedTime;pwd-userPassword: 20000103121520Z
#
#   This attribute option follows sub-typing semantics.  If a client
#   requests a password policy state attribute to be returned in a search
#   operation, and does not specify an option, all subtypes of that
#   policy state attribute are returned.
#
#5.3.2  pwdChangedTime
#
#   This attribute specifies the last time the entry's password was
#   changed.  This is used by the password expiration policy.  If this
#   attribute does not exist, the password will never expire.
#
#      ( 1.3.6.1.4.1.42.2.27.8.1.16
#      NAME 'pwdChangedTime'
#      DESC 'The time the password was last changed'
#      EQUALITY generalizedTimeMatch
#      ORDERING generalizedTimeOrderingMatch
#      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
#      SINGLE-VALUE
#      USAGE directoryOperation )
#
#5.3.3  pwdAccountLockedTime
#
#   This attribute holds the time that the user's account was locked.  A
#   locked account means that the password may no longer be used to
#   authenticate.  A 000001010000Z value means that the account has been
#   locked permanently, and that only a password administrator can unlock
#   the account.
#
#      ( 1.3.6.1.4.1.42.2.27.8.1.17
#      NAME 'pwdAccountLockedTime'
#      DESC 'The time an user account was locked'
#      EQUALITY generalizedTimeMatch
#      ORDERING generalizedTimeOrderingMatch
#      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
#      SINGLE-VALUE
#      USAGE directoryOperation )
#
#5.3.4  pwdFailureTime
#
#   This attribute holds the timestamps of the consecutive authentication
#   failures.
#
#      ( 1.3.6.1.4.1.42.2.27.8.1.19
#      NAME 'pwdFailureTime'
#      DESC 'The timestamps of the last consecutive authentication
#      failures'
#      EQUALITY generalizedTimeMatch
#      ORDERING generalizedTimeOrderingMatch
#      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
#      USAGE directoryOperation )
#
#5.3.5  pwdHistory
#
#   This attribute holds a history of previously used passwords.  Values
#   of this attribute are transmitted in string format as given by the
#   following ABNF:
#
#   pwdHistory = time "#" syntaxOID "#" length "#" data
#
#   time       = <generalizedTimeString as specified in 6.14
#                 of [RFC2252]>
#
#   syntaxOID  = numericoid    ; the string representation of the
#                              ; dotted-decimal OID that defines the
#                              ; syntax used to store the password.
#                              ; numericoid is described in 4.1
#                              ; of [RFC2252].
#
#   length     = numericstring ; the number of octets in data.
#                              ; numericstring is described in 4.1
#                              ; of [RFC2252].
#
#   data       = <octets representing the password in the format
#                 specified by syntaxOID>.
#
#   This format allows the server to store, and transmit a history of
#   passwords that have been used.  In order for equality matching to
#   function properly, the time field needs to adhere to a consistent
#   format.  For this purpose, the time field MUST be in GMT format.
#
#      ( 1.3.6.1.4.1.42.2.27.8.1.20
#      NAME 'pwdHistory'
#      DESC 'The history of user s passwords'
#      EQUALITY octetStringMatch
#      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
#      USAGE directoryOperation )
#
#5.3.6  pwdGraceUseTime
#
#   This attribute holds the timestamps of grace authentications after a
#   password has expired.
#
#      ( 1.3.6.1.4.1.42.2.27.8.1.21
#      NAME 'pwdGraceUseTime'
#      DESC 'The timestamps of the grace authentication after the
#      password has expired'
#      EQUALITY generalizedTimeMatch
#      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
#
#5.3.7  pwdReset
#
#   This attribute holds a flag to indicate (when TRUE) that the password
#   has been updated by the password administrator and must be changed by
#   the user on first authentication.
#
#      ( 1.3.6.1.4.1.42.2.27.8.1.22
#      NAME 'pwdReset'
#      DESC 'The indication that the password has been reset'
#      EQUALITY booleanMatch
#      SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
#      SINGLE-VALUE
#      USAGE directoryOperation )
#
#5.3.8  pwdPolicySubentry
#
#   This attribute points to the pwdPolicy subentry in effect for this
#   object.
#
#      ( 1.3.6.1.4.1.42.2.27.8.1.23
#      NAME 'pwdPolicySubentry'
#      DESC 'The pwdPolicy subentry in effect for this object'
#      EQUALITY distinguishedNameMatch
#      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
#      SINGLE-VALUE
#      USAGE directoryOperation )
#
# <MODIFIED> Mozilla extension
# 5.3.10  pwdUniqueAttempts
# This attribute holds a history of previously failed passwords 
# attempts up to the limit defined by pwdMaxFailure. Values of this
# attribute are transmitted in string format as given by the following
# ABNF:
#
#  pwdUniqueAttempts = time "#" count "#" length "#" data
#
#  time       = <generalizedTimeString as specified in 6.14
#                of [RFC2252]>.
#
#  count  = Integer    ;       the count of uses of this password
#                             ;Integer is described in 6.16 of [RFC2252]
#
#  length     = numericstring ; the number of octets in data.
#                             ; numericstring is described in 4.1
#                             ; of [RFC2252].
#
#  data       = <octets representing the password in the default hash format
#             for the server
#
# In order for equality matching to function properly, the time field 
# needs to adhere to a consistent format.  For this purpose, the time 
# field MUST be in GMT (UCT) format. The time field is set only when 
# the attribute is initially added.
#
#     (1.3.6.1.4.1.13769.1.3.2
#     NAME 'pwdUniqueAttempts'
#     DESC 'History of unique passwords attempts'
#     EQUALITY octetStringMatch
#     SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
#     NO-USER-MODIFICATION
#     USAGE directoryOperation )
# When a failed password attempt occurs and the value of pwdMaxTotalAttempts
# is non 0 then pwdUniqueAttempts is searched for a match. If a match occurs
# then the count field of this entry is incremented only if the value of 
# pwdMaxTotalAttempts is positive. If no match occurs then an entry is made 
# in pwdFailureTime and in pwdUniqueAttempts (with a count field value of 1). 
# If pwdMaxTotalAttempts is positive then when the sum of the count field 
# values of all items in pwdUniqueAttempts equals pwdMaxTotalAttempts the 
# action taken is defined by pwdLockout.
</MODIFIED>

#Disclaimer of Validity
#
#   This document and the information contained herein are provided on an
#   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
#   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
#   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
#   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
#   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
#   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
#
#
#Copyright Statement
#
#   Copyright (C) The Internet Society (2004).  This document is subject
#   to the rights, licenses and restrictions contained in BCP 78, and
#   except as set forth therein, the authors retain all their rights.

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# Java Object Schema
# $OpenLDAP: pkg/ldap/servers/slapd/schema/java.schema,
# v 1.1.2.2 2000/09/13 18:16:13 kurt Exp $
# depends upon core.schema

# Network Working Group                                            V. Ryan
# Request for Comments: 2713                                   S. Seligman
# Category: Informational                                           R. Lee
#                                                   Sun Microsystems, Inc.
#                                                             October 1999
# 
# 
#      Schema for Representing Java(tm) Objects in an LDAP Directory
# 
# Status of this Memo
# 
#    This memo provides information for the Internet community.  It does
#    not specify an Internet standard of any kind.  Distribution of this
#    memo is unlimited.
# 
# Copyright Notice
# 
#    Copyright (C) The Internet Society (1999).  All Rights Reserved.
# 
# Abstract
# 
#    This document defines the schema for representing Java(tm) objects in
#    an LDAP directory [LDAPv3].  It defines schema elements to represent
#    a Java serialized object [Serial], a Java marshalled object [RMI], a
#    Java remote object [RMI], and a JNDI reference [JNDI].
# 

# [trimmed]

# 3 Attribute Type Definitions
# 
#    The following attribute types are defined in this document:
# 
#        javaClassName
#        javaClassNames
#        javaCodebase
#        javaSerializedData
#        javaFactory
#        javaReferenceAddress
#        javaDoc
# 
# 3.1 javaClassName
# 
#    This attribute stores the fully qualified name of the Java object's
#    "distinguished" class or interface (for example, "java.lang.String").
#    It is a single-valued attribute. This attribute's syntax is '
#    Directory String' and its case is significant.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.1.6
#          NAME 'javaClassName'
#          DESC 'Fully qualified name of distinguished Java class or
#                interface'
#          EQUALITY caseExactMatch
#          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
#          SINGLE-VALUE
#        )
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.6
	NAME 'javaClassName'
	DESC 'Fully qualified name of distinguished Java class or interface'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )
 
# 3.2 javaCodebase
# 
#    This attribute stores the Java class definition's locations.  It
#    specifies the locations from which to load the class definition for
#    the class specified by the javaClassName attribute.  Each value of
#    the attribute contains an ordered list of URLs, separated by spaces.
#    For example, a value of "url1 url2 url3" means that the three
#    (possibly interdependent) URLs (url1, url2, and url3) form the
#    codebase for loading in the Java class definition.
# 
#    If the javaCodebase attribute contains more than one value, each
#    value is an independent codebase. That is, there is no relationship
#    between the URLs in one value and those in another; each value can be
#    viewed as an alternate source for loading the Java class definition.
#    See [Java] for information regarding class loading.
# 
#    This attribute's syntax is 'IA5 String' and its case is significant.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.1.7
#          NAME 'javaCodebase'
#          DESC 'URL(s) specifying the location of class definition'
#          EQUALITY caseExactIA5Match
#          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
#        )
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.7
	NAME 'javaCodebase'
	DESC 'URL(s) specifying the location of class definition'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 3.3 javaClassNames
# 
#    This attribute stores the Java object's fully qualified class or
#    interface names (for example, "java.lang.String").  It is a
#    multivalued attribute. When more than one value is present, each is
#    the name of a class or interface, or ancestor class or interface, of
#    this object.
# 
#    This attribute's syntax is 'Directory String' and its case is
#    significant.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.1.13
#          NAME 'javaClassNames'
#          DESC 'Fully qualified Java class or interface name'
#          EQUALITY caseExactMatch
#          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
#        )
# 
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.13
	NAME 'javaClassNames'
	DESC 'Fully qualified Java class or interface name'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
 
# 3.4 javaSerializedData
# 
#    This attribute stores the serialized form of a Java object.  The
#    serialized form is described in [Serial].
# 
#    This attribute's syntax is 'Octet String'.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.1.8
#          NAME 'javaSerializedData
#          DESC 'Serialized form of a Java object'
#          SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
#          SINGLE-VALUE
#        )
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.8
	NAME 'javaSerializedData'
	DESC 'Serialized form of a Java object'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
	SINGLE-VALUE )

# 3.5 javaFactory
# 
#    This attribute stores the fully qualified class name of the object
#    factory (for example, "com.wiz.jndi.WizObjectFactory") that can be
#    used to create an instance of the object identified by the
#    javaClassName attribute.
# 
#    This attribute's syntax is 'Directory String' and its case is
#    significant.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.1.10
#          NAME 'javaFactory'
#          DESC 'Fully qualified Java class name of a JNDI object factory'
#          EQUALITY caseExactMatch
#          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
#          SINGLE-VALUE
#        )
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.10
	NAME 'javaFactory'
	DESC 'Fully qualified Java class name of a JNDI object factory'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE )

# 3.6 javaReferenceAddress
# 
#    This attribute represents the sequence of addresses of a JNDI
#    reference.  Each of its values represents one address, a Java object
#    of type javax.naming.RefAddr.  Its value is a concatenation of the
#    address type and address contents, preceded by a sequence number (the
#    order of addresses in a JNDI reference is significant).  For example:
# 
#        #0#TypeA#ValA
#        #1#TypeB#ValB
#        #2#TypeC##rO0ABXNyABpq...
# 
#    In more detail, the value is encoded as follows:
# 
#    The delimiter is the first character of the value.  For readability
#    the character '#' is recommended when it is not otherwise used
#    anywhere in the value, but any character may be used subject to
#    restrictions given below.
# 
#    The first delimiter is followed by the sequence number.  The sequence
#    number of an address is its position in the JNDI reference, with the
#    first address being numbered 0.  It is represented by its shortest
#    string form, in decimal notation.
# 
#    The sequence number is followed by a delimiter, then by the address
#    type, and then by another delimiter.  If the address is of Java class
#    javax.naming.StringRefAddr, then this delimiter is followed by the
#    value of the address contents (which is a string).  Otherwise, this
#    delimiter is followed immediately by another delimiter, and then by
#    the Base64 encoding of the serialized form of the entire address.
# 
#    The delimiter may be any character other than a digit or a character
#    contained in the address type.  In addition, if the address contents
#    is a string, the delimiter may not be the first character of that
#    string.
# 
#    This attribute's syntax is 'Directory String' and its case is
#    significant.  It can contain multiple values.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.1.11
#          NAME 'javaReferenceAddress'
#          DESC 'Addresses associated with a JNDI Reference'
#          EQUALITY caseExactMatch
#          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
#        )
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.11
	NAME 'javaReferenceAddress'
	DESC 'Addresses associated with a JNDI Reference'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 3.7 javaDoc
# 
#    This attribute stores a pointer to the Java documentation for the
#    class.  It's value is a URL. For example, the following URL points to
#    the specification of the java.lang.String class:
#    http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html
# 
#    This attribute's syntax is 'IA5 String' and its case is significant.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.1.12
#          NAME 'javaDoc'
#          DESC 'The Java documentation for the class'
#          EQUALITY caseExactIA5Match
#          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
#        )
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.12
	NAME 'javaDoc'
	DESC 'The Java documentation for the class'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# 4 Object Class Definitions
# 
#    The following object classes are defined in this document:
# 
#        javaContainer
#        javaObject
#        javaSerializedObject
#        javaMarshalledObject
#        javaNamingReference
# 
# 4.1 javaContainer
# 
#    This structural object class represents a container for a Java
#    object.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.2.1
#          NAME 'javaContainer'
#          DESC 'Container for a Java object'
#          SUP top
#          STRUCTURAL
#          MUST ( cn )
#        )
# 
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.1
	NAME 'javaContainer'
	DESC 'Container for a Java object'
	SUP top
	STRUCTURAL
	MUST cn )

# 4.2 javaObject
# 
#    This abstract object class represents a Java object.  A javaObject
#    cannot exist in the directory; only auxiliary or structural
#    subclasses of it can exist in the directory.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.2.4
#          NAME 'javaObject'
#          DESC 'Java object representation'
#          SUP top
#          ABSTRACT
#          MUST ( javaClassName )
#          MAY ( javaClassNames $
#                javaCodebase $
#                javaDoc $
#                description )
#        )
# 
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.4
	NAME 'javaObject'
	DESC 'Java object representation'
	SUP top
	ABSTRACT
	MUST javaClassName
	MAY ( javaClassNames $ javaCodebase $
		javaDoc $ description ) )

# 4.3 javaSerializedObject
# 
#    This auxiliary object class represents a Java serialized object.  It
#    must be mixed in with a structural object class.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.2.5
#          NAME 'javaSerializedObject'
#          DESC 'Java serialized object'
#          SUP javaObject
#          AUXILIARY
#          MUST ( javaSerializedData )
#        )
# 
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.5
	NAME 'javaSerializedObject'
	DESC 'Java serialized object'
	SUP javaObject
	AUXILIARY
	MUST javaSerializedData )
 
# 4.4 javaMarshalledObject
# 
#    This auxiliary object class represents a Java marshalled object.  It
#    must be mixed in with a structural object class.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.2.8
#          NAME 'javaMarshalledObject'
#          DESC 'Java marshalled object'
#          SUP javaObject
#          AUXILIARY
#          MUST ( javaSerializedData )
#        )
# 
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.8
	NAME 'javaMarshalledObject'
	DESC 'Java marshalled object'
	SUP javaObject
	AUXILIARY
	MUST javaSerializedData )

# 4.5 javaNamingReference
# 
#    This auxiliary object class represents a JNDI reference.  It must be
#    mixed in with a structural object class.
# 
#        ( 1.3.6.1.4.1.42.2.27.4.2.7
#          NAME 'javaNamingReference'
#          DESC 'JNDI reference'
#          SUP javaObject
#          AUXILIARY
#          MAY ( javaReferenceAddress $
#                javaFactory )
#        )
# 
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.7
	NAME 'javaNamingReference'
	DESC 'JNDI reference'
	SUP javaObject
	AUXILIARY
	MAY ( javaReferenceAddress $ javaFactory ) )
 
# Full Copyright Statement
# 
#    Copyright (C) The Internet Society (1999).  All Rights Reserved.
# 
#    This document and translations of it may be copied and furnished to
#    others, and derivative works that comment on or otherwise explain it
#    or assist in its implementation may be prepared, copied, published
#    and distributed, in whole or in part, without restriction of any
#    kind, provided that the above copyright notice and this paragraph are
#    included on all such copies and derivative works.  However, this
#    document itself may not be modified in any way, such as by removing
#    the copyright notice or references to the Internet Society or other
#    Internet organizations, except as needed for the purpose of
#    developing Internet standards in which case the procedures for
#    copyrights defined in the Internet Standards process must be
#    followed, or as required to translate it into languages other than
#    English.
# 
#    The limited permissions granted above are perpetual and will not be
#    revoked by the Internet Society or its successors or assigns.
# 
#    This document and the information contained herein is provided on an
#    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
#    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
#    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
#    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
#    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Этот набор схемы данных распространяется со стандартным дистрибутивом qmail.

#
# qmail-ldap v3 directory schema
#
# The offical qmail-ldap OID assigned by IANA is 7914
#
# Created by: David E. Storey <dave@tamos.net>
# Modified and included into qmail-ldap by Andre Oppermann <opi@nrg4u.com>
#
# I've gone through this schema and I think it is now correct but I'm
# not 100% certain. The next release will clear it up.
#
# This schema depends on:
#	- core.schema
#	- cosine.schema
#

# Attribute Type Definitions

attributetype ( 1.3.6.1.4.1.7914.1.2.1.1 NAME 'qmailUID'
  DESC 'UID of the user on the mailsystem'
  EQUALITY integerMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
  SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.2 NAME 'qmailGID'
  DESC 'GID of the user on the mailsystem'
  EQUALITY integerMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
  SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.3 NAME 'mailMessageStore'
  DESC 'Path to the maildir/mbox on the mail system'
  EQUALITY caseExactIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.4 NAME 'mailAlternateAddress'
  SUBSTR caseIgnoreSubstringsMatch
  DESC 'Secondary (alias) mailaddresses for the same user'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.5 NAME 'mailQuota'
  DESC 'The amount of space the user can use until all further messages get bounced.'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
  SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.6 NAME 'mailHost'
  DESC 'On which qmail server the messagestore of this user is located.'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
  SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.7 NAME 'mailForwardingAddress'
  DESC 'Address(es) to forward all incoming messages to.'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.8 NAME 'deliveryProgramPath'
  DESC 'Program to execute for all incoming mails.'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.9 NAME 'qmailDotMode'
  DESC 'Interpretation of .qmail files: both, dotonly, ldaponly, ldapwithprog, none'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
  SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.10 NAME 'deliveryMode'
  DESC 'multi field entries of: normal, forwardonly, nombox, localdelivery, reply, echo'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.11 NAME 'mailReplyText'
  DESC 'A reply text for every incoming message'
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{4096}
  SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7914.1.2.1.12 NAME 'accountStatus'
  DESC 'The status of a user account: active, nopop, disabled'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
  SINGLE-VALUE )

# Object Class Definitions

objectclass ( 1.3.6.1.4.1.7914.1.2.2.1 NAME 'qmailUser'
  DESC 'QMail-LDAP User' SUP top AUXILIARY
  MUST ( mail $ uid )
  MAY ( mailMessageStore $ homeDirectory $ userPassword $
     mailAlternateAddress $ qmailUID $ qmailGID $ mailQuota $
     mailHost $ mailForwardingAddress $ deliveryProgramPath $
     qmailDotMode $ deliveryMode $ mailReplyText $
     accountStatus ) )

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# Corba Object Schema
# $OpenLDAP: pkg/ldap/servers/slapd/schema/corba.schema,
# v 1.1.2.1 2000/09/13 00:42:36 kurt Exp $
# depends upon core.schema

# Network Working Group                                            V. Ryan
# Request for Comments: 2714                                        R. Lee
# Category: Informational                                      S. Seligman
#                                                   Sun Microsystems, Inc.
#                                                             October 1999
# 
# 
#   Schema for Representing CORBA Object References in an LDAP Directory
# 
# Status of this Memo
# 
#    This memo provides information for the Internet community.  It does
#    not specify an Internet standard of any kind.  Distribution of this
#    memo is unlimited.
# 
# Copyright Notice
# 
#    Copyright (C) The Internet Society (1999).  All Rights Reserved.
# 
# Abstract
# 
#    CORBA [CORBA] is the Common Object Request Broker Architecture
#    defined by the Object Management Group. This document defines the
#    schema for representing CORBA object references in an LDAP directory
#    [LDAPv3].
# 
# [trimmed]

# 3. Attribute Type Definitions
# 
#    The following attribute types are defined in this document:
# 
#        corbaIor
#        corbaRepositoryId
# 
# 3.1 corbaIor
# 
#    This attribute stores the string representation of the interoperable
#    object reference (IOR) for a CORBA object. An IOR is an opaque handle
#    for the object which contains the information necessary to locate the
#    object, even if the object is in another ORB.
# 
#    This attribute's syntax is 'IA5 String' and its case is
#    insignificant.
# 
#    ( 1.3.6.1.4.1.42.2.27.4.1.14
#     NAME 'corbaIor'
#     DESC 'Stringified interoperable object reference of a CORBA object'
#     EQUALITY caseIgnoreIA5Match
#     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
#     SINGLE-VALUE
#    )
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.14
	NAME 'corbaIor'
	DESC 'Stringified interoperable object reference of a CORBA object'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
	SINGLE-VALUE )

# 3.2 corbaRepositoryId
# 
#    Each CORBA interface has a unique "repository id" (also called "type
#    id") that identifies the interface.  A CORBA object has one or more
#    repository ids, one for each interface that it implements.
# 
#    The format of a repository id can be any string, but the OMG
#    specifies four standard formats:
# 
#       a. IDL-style
# 
#        IDL:Prefix/ModuleName/InterfaceName:VersionNumber
# 
#    For example, the repository id for the "NamingContext" in OMG's COS
#    Naming module is:  "IDL:omg.org/CosNaming/NamingContext:1.0".
# 
#       b. RMI-style
# 
#        RMI:ClassName:HashCode[:SUID]
# 
#    This format is used by RMI-IIOP remote objects [RMI-IIOP].
#    "ClassName" is the fully qualified name of the class (for example,
#    "java.lang.String"). "HashCode" is the object's hash code (that is,
#    that obtained by invoking the "hashCode()" method).  "SUID" is the
#    "stream unique identifier", which is a 64-bit number that uniquely
#    identifies the serialization version of the class; SUID is optional
#    in the repository id.
# 
#       c. DCE-style
# 
#        DCE:UUID
# 
#    This format is used for DCE/CORBA interoperability [CORBA-DCE].
#    "UUID" represents a DCE UUID.
# 
#       d. "local"
# 
#    This format is defined by the local Object Request Broker (ORB).
# 
#    The corbaRepositoryId attribute is a multivalued attribute; each
#    value records a single repository id of an interface implemented by
#    the CORBA object.  This attribute need not contain a complete list of
#    the interfaces implemented by the CORBA object.
# 
#    This attribute's syntax is 'Directory String' and its case is
#    significant.  The values of this attribute are encoded using UTF-8.
#    Some values may require translation from their native representation
#    in order to be correctly encoded using UTF-8.
# 
#    ( 1.3.6.1.4.1.42.2.27.4.1.15
#     NAME 'corbaRepositoryId'
#     DESC 'Repository ids of interfaces implemented by a CORBA object'
#     EQUALITY caseExactMatch
#     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
#    )
# 
# 
attributetype ( 1.3.6.1.4.1.42.2.27.4.1.15
	NAME 'corbaRepositoryId'
	DESC 'Repository ids of interfaces implemented by a CORBA object'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# 4. Object Class Definitions
# 
#    The following object classes are defined in this document:
# 
#        corbaContainer
#        corbaObject
#        corbaObjectReference
# 
# 4.1 corbaContainer
# 
#    This structural object class represents a container for a CORBA
#    object.
# 
#    ( 1.3.6.1.4.1.42.2.27.4.2.10
#     NAME 'corbaContainer'
#     DESC 'Container for a CORBA object'
#     SUP top
#     STRUCTURAL
#     MUST ( cn )
#    )
# 
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.10
	NAME 'corbaContainer'
	DESC 'Container for a CORBA object'
	SUP top
	STRUCTURAL
	MUST cn )

# 4.2 corbaObject
# 
#    This abstract object class is the root class for representing a CORBA
#    object.
# 
#    ( 1.3.6.1.4.1.42.2.27.4.2.9
#     NAME 'corbaObject'
#     DESC 'CORBA object representation'
#     SUP top
#     ABSTRACT
#     MAY ( corbaRepositoryId $ description )
#    )
# 
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.9
	NAME 'corbaObject'
	DESC 'CORBA object representation'
	SUP top
	ABSTRACT
	MAY ( corbaRepositoryId $ description ) )

# 4.3 corbaObjectReference
# 
#    This auxiliary object class represents a CORBA object reference.  It
#    must be mixed in with a structural object class.
# 
#    ( 1.3.6.1.4.1.42.2.27.4.2.11
#     NAME 'corbaObjectReference'
#     DESC 'CORBA interoperable object reference'
#     SUP corbaObject
#     AUXILIARY
#     MUST ( corbaIor )
#    )
# 
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.11
	NAME 'corbaObjectReference'
	DESC 'CORBA interoperable object reference'
	SUP corbaObject
	AUXILIARY
	MUST corbaIor )
 

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# dyngroup.schema -- Dynamic Group schema
# $OpenLDAP: pkg/ldap/servers/slapd/schema/dyngroup.schema,v 1.6.2.4 2008/02/12 05:17:43 quanah Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2008 The OpenLDAP Foundation.
## All rights reserved.
##
## Redistribution and use in source and binary forms, with or without
## modification, are permitted only as authorized by the OpenLDAP
## Public License.
##
## A copy of this license is available in the file LICENSE in the
## top-level directory of the distribution or, alternatively, at
## <http://www.OpenLDAP.org/license.html>.
#
# Dynamic Group schema (experimental), as defined by Netscape.  See
# http://www.redhat.com/docs/manuals/ent-server/pdf/esadmin611.pdf
# page 70 for details on how these groups were used.
#
# A description of the objectclass definition is available here:
# http://www.redhat.com/docs/manuals/dir-server/schema/7.1/oc_dir.html#1303745
#
# depends upon:
#	core.schema
#
# These definitions are considered experimental due to the lack of
# a formal specification (e.g., RFC).
#
# NOT RECOMMENDED FOR PRODUCTION USE!  USE WITH CAUTION!
#
# The Netscape documentation describes this as an auxiliary objectclass
# but their implementations have always defined it as a structural class.
# The sloppiness here is because Netscape-derived servers don't actually
# implement the X.500 data model, and they don't honor the distinction
# between structural and auxiliary classes. This fact is noted here:
# http://forum.java.sun.com/thread.jspa?threadID=5016864&messageID=9034636
#
# In accordance with other existing implementations, we define it as a
# structural class.
#
# Our definition of memberURL also does not match theirs but again
# their published definition and what works in practice do not agree.
# In other words, the Netscape definitions are broken and interoperability
# is not guaranteed.
#
# Also see the new DynGroup proposed spec at
# http://tools.ietf.org/html/draft-haripriya-dynamicgroup-02

objectIdentifier NetscapeRoot 2.16.840.1.113730

objectIdentifier NetscapeLDAP NetscapeRoot:3
objectIdentifier NetscapeLDAPattributeType NetscapeLDAP:1
objectIdentifier NetscapeLDAPobjectClass NetscapeLDAP:2

objectIdentifier OpenLDAPExp11	1.3.6.1.4.1.4203.666.11
objectIdentifier DynGroupBase	OpenLDAPExp11:8
objectIdentifier DynGroupAttr	DynGroupBase:1
objectIdentifier DynGroupOC	DynGroupBase:2

attributetype ( NetscapeLDAPattributeType:198
	NAME 'memberURL'
	DESC 'Identifies an URL associated with each member of a group. Any type of labeled URL can be used.'
	SUP labeledURI )

attributetype ( DynGroupAttr:1
	NAME 'dgIdentity'
	DESC 'Identity to use when processing the memberURL'
	SUP distinguishedName SINGLE-VALUE )

attributeType ( DynGroupAttr:2
	NAME 'dgAuthz'
	DESC 'Optional authorization rules that determine who is allowed to assume the dgIdentity'
	EQUALITY authzMatch
	SYNTAX 1.3.6.1.4.1.4203.666.2.7
	X-ORDERED 'VALUES' )

objectClass ( NetscapeLDAPobjectClass:33
	NAME 'groupOfURLs'
	SUP top STRUCTURAL
	MUST cn
	MAY ( memberURL $ businessCategory $ description $ o $ ou $
		owner $ seeAlso ) )

# The Haripriya dyngroup schema still needs a lot of work.
# We're just adding support for the dgIdentity attribute for now...
objectClass ( DynGroupOC:1
	NAME 'dgIdentityAux'
	SUP top AUXILIARY
	MAY ( dgIdentity $ dgAuthz ) )

Эта схема распространяется со стандартным дистрибутивом Samba 3.x (во FreeBSD /usr/local/share/examples/samba/Ldap/samba.schema). Данный набор схемы идёт со стандартным портом FreeBSD. После чтения документации создаётся впечатление, что разработчики некоторых дистрибутивов linux забывают, что они делают общее дело, и переименовывают данный набор схемы в samba3.schema. Примечание: во избежание путаницы мы удалили закомментированную старую (историческую) секцию Samaba 2.x.

##
## schema file for Samba 3.x
## Schema for storing Samba user accounts and group maps in LDAP
## OIDs are owned by the Samba Team
##
## Prerequisite schemas - uid         (cosine.schema)
##                      - displayName (inetorgperson.schema)
##                      - gidNumber   (nis.schema)
##
## 1.3.6.1.4.1.7165.2.1.x - attributetypes
## 1.3.6.1.4.1.7165.2.2.x - objectclasses
##

#######################################################################
##                Attributes used by Samba 3.0 schema                ##
#######################################################################

##
## Password hashes
##
attributetype ( 1.3.6.1.4.1.7165.2.1.24 NAME 'sambaLMPassword'
	DESC 'LanManager Password'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.25 NAME 'sambaNTPassword'
	DESC 'MD4 hash of the unicode password'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE )

##
## Account flags in string format ([UWDX     ])
##
attributetype ( 1.3.6.1.4.1.7165.2.1.26 NAME 'sambaAcctFlags'
	DESC 'Account Flags'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{16} SINGLE-VALUE )

##
## Password timestamps & policies
##
attributetype ( 1.3.6.1.4.1.7165.2.1.27 NAME 'sambaPwdLastSet'
	DESC 'Timestamp of the last password update'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.28 NAME 'sambaPwdCanChange'
	DESC 'Timestamp of when the user is allowed to update the password'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.29 NAME 'sambaPwdMustChange'
	DESC 'Timestamp of when the password will expire'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.30 NAME 'sambaLogonTime'
	DESC 'Timestamp of last logon'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.31 NAME 'sambaLogoffTime'
	DESC 'Timestamp of last logoff'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.32 NAME 'sambaKickoffTime'
	DESC 'Timestamp of when the user will be logged off automatically'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.48 NAME 'sambaBadPasswordCount'
	DESC 'Bad password attempt count'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.49 NAME 'sambaBadPasswordTime'
	DESC 'Time of the last bad password attempt'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )


##
## string settings
##
attributetype ( 1.3.6.1.4.1.7165.2.1.33 NAME 'sambaHomeDrive'
	DESC 'Driver letter of home directory mapping'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{4} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.34 NAME 'sambaLogonScript'
	DESC 'Logon script path'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.35 NAME 'sambaProfilePath'
	DESC 'Roaming profile path'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.36 NAME 'sambaUserWorkstations'
	DESC 'List of user workstations the user is allowed to logon to'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.37 NAME 'sambaHomePath'
	DESC 'Home directory UNC path'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7165.2.1.38 NAME 'sambaDomainName'
	DESC 'Windows NT domain to which the user belongs'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7165.2.1.47 NAME 'sambaMungedDial'
	DESC ''
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1050} )

##
## SID, of any type
##

attributetype ( 1.3.6.1.4.1.7165.2.1.20 NAME 'sambaSID'
	DESC 'Security ID'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{64} SINGLE-VALUE )


##
## Primary group SID, compatible with ntSid
##

attributetype ( 1.3.6.1.4.1.7165.2.1.23 NAME 'sambaPrimaryGroupSID'
	DESC 'Primary Group Security ID'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{64} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.51 NAME 'sambaSIDList'
	DESC 'Security ID List'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{64} )

##
## group mapping attributes
##
attributetype ( 1.3.6.1.4.1.7165.2.1.19 NAME 'sambaGroupType'
	DESC 'NT Group Type'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

##
## Store info on the domain
##

attributetype ( 1.3.6.1.4.1.7165.2.1.21 NAME 'sambaNextUserRid'
	DESC 'Next NT rid to give our for users'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.22 NAME 'sambaNextGroupRid'
	DESC 'Next NT rid to give out for groups'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.39 NAME 'sambaNextRid'
	DESC 'Next NT rid to give out for anything'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.7165.2.1.40 NAME 'sambaAlgorithmicRidBase'
	DESC 'Base at which the samba RID generation algorithm should operate'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )


#######################################################################
##              objectClasses used by Samba 3.0 schema               ##
#######################################################################

## The X.500 data model (and therefore LDAPv3) says that each entry can
## only have one structural objectclass.  OpenLDAP 2.0 does not enforce
## this currently but will in v2.1

##
## added new objectclass (and OID) for 3.0 to help us deal with backwards
## compatibility with 2.2 installations (e.g. ldapsam_compat)  --jerry
##
objectclass ( 1.3.6.1.4.1.7165.2.2.6 NAME 'sambaSamAccount' SUP top AUXILIARY
  DESC 'Samba 3.0 Auxilary SAM Account'
  MUST ( uid $ sambaSID )
  MAY  ( cn $ sambaLMPassword $ sambaNTPassword $ sambaPwdLastSet $
     sambaLogonTime $ sambaLogoffTime $ sambaKickoffTime $
     sambaPwdCanChange $ sambaPwdMustChange $ sambaAcctFlags $
     displayName $ sambaHomePath $ sambaHomeDrive $ sambaLogonScript $
     sambaProfilePath $ description $ sambaUserWorkstations $
     sambaPrimaryGroupSID $ sambaDomainName $ sambaMungedDial $
     sambaBadPasswordCount $ sambaBadPasswordTime))

##
## Group mapping info
##
objectclass ( 1.3.6.1.4.1.7165.2.2.4 NAME 'sambaGroupMapping' SUP top AUXILIARY
  DESC 'Samba Group Mapping'
  MUST ( gidNumber $ sambaSID $ sambaGroupType )
  MAY  ( displayName $ description $ sambaSIDList ))

##
## Whole-of-domain info
##
objectclass ( 1.3.6.1.4.1.7165.2.2.5 NAME 'sambaDomain' SUP top STRUCTURAL
  DESC 'Samba Domain Information'
  MUST ( sambaDomainName $ sambaSID ) 
  MAY ( sambaNextRid $ sambaNextGroupRid $ sambaNextUserRid $
    sambaAlgorithmicRidBase ) )

## used for idmap_ldap module
objectclass ( 1.3.6.1.4.1.7165.1.2.2.7 NAME 'sambaUnixIdPool' SUP top AUXILIARY
  DESC 'Pool for allocating UNIX uids/gids'
  MUST ( uidNumber $ gidNumber ) )


objectclass ( 1.3.6.1.4.1.7165.1.2.2.8 NAME 'sambaIdmapEntry' SUP top AUXILIARY
  DESC 'Mapping from a SID to an ID'
  MUST ( sambaSID )
  MAY ( uidNumber $ gidNumber ) )

objectclass ( 1.3.6.1.4.1.7165.1.2.2.9 NAME 'sambaSidEntry' SUP top STRUCTURAL
  DESC 'Structural Class for a SID'
  MUST ( sambaSID ) )

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# $OpenLDAP: pkg/ldap/servers/slapd/schema/openldap.schema,v 1.24.2.4 
# 2008/02/11 23:26:49 kurt Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2008 The OpenLDAP Foundation.
## All rights reserved.
##
## Redistribution and use in source and binary forms, with or without
## modification, are permitted only as authorized by the OpenLDAP
## Public License.
##
## A copy of this license is available in the file LICENSE in the
## top-level directory of the distribution or, alternatively, at
## <http://www.OpenLDAP.org/license.html>.

#
# OpenLDAP Project's directory schema items
#
# depends upon:
#	core.schema
#	cosine.schema
#	inetorgperson.schema
#
# These are provided for informational purposes only.

objectIdentifier OpenLDAProot 1.3.6.1.4.1.4203

objectIdentifier OpenLDAP OpenLDAProot:1
objectIdentifier OpenLDAPattributeType OpenLDAP:3
objectIdentifier OpenLDAPobjectClass OpenLDAP:4

objectClass ( OpenLDAPobjectClass:3
	NAME 'OpenLDAPorg'
	DESC 'OpenLDAP Organizational Object'
	SUP organization
	MAY ( buildingName $ displayName $ labeledURI ) )

objectClass ( OpenLDAPobjectClass:4
	NAME 'OpenLDAPou'
	DESC 'OpenLDAP Organizational Unit Object'
	SUP organizationalUnit
	MAY ( buildingName $ displayName $ labeledURI $ o ) )

objectClass ( OpenLDAPobjectClass:5
	NAME 'OpenLDAPperson'
	DESC 'OpenLDAP Person'
	SUP ( pilotPerson $ inetOrgPerson )
	MUST ( uid $ cn )
	MAY ( givenName $ labeledURI $ o ) )

objectClass ( OpenLDAPobjectClass:6
	NAME 'OpenLDAPdisplayableObject'
	DESC 'OpenLDAP Displayable Object'
	AUXILIARY
	MAY displayName )

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# misc.schema -- assorted schema definitions
# $OpenLDAP: pkg/ldap/servers/slapd/schema/misc.schema,v 1.27.2.4 2008/02/11 23:24:26 kurt Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2008 The OpenLDAP Foundation.
## All rights reserved.
##
## Redistribution and use in source and binary forms, with or without
## modification, are permitted only as authorized by the OpenLDAP
## Public License.
##
## A copy of this license is available in the file LICENSE in the
## top-level directory of the distribution or, alternatively, at
## <http://www.OpenLDAP.org/license.html>.
#
# Assorted definitions from several sources, including
# ''works in progress''.  Contents of this file are
# subject to change (including deletion) without notice.
#
# Not recommended for production use!
# Use with extreme caution!

#-----------------------------------------------------------
# draft-lachman-laser-ldap-mail-routing-02.txt !!!EXPIRED!!!
#	(a work in progress)
#
attributetype ( 2.16.840.1.113730.3.1.13
	NAME 'mailLocalAddress'
	DESC 'RFC822 email address of this recipient'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

attributetype ( 2.16.840.1.113730.3.1.18
	NAME 'mailHost'
	DESC 'FQDN of the SMTP/MTA of this recipient'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
	SINGLE-VALUE )

attributetype ( 2.16.840.1.113730.3.1.47
	NAME 'mailRoutingAddress'
	DESC 'RFC822 routing address of this recipient'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
	SINGLE-VALUE )

# I-D leaves this OID TBD.
# iPlanet uses 2.16.840.1.113.730.3.2.147 but that is an
# improperly delegated OID.  A typo is likely.
objectclass ( 2.16.840.1.113730.3.2.147
	NAME 'inetLocalMailRecipient'
	DESC 'Internet local mail recipient'
	SUP top AUXILIARY
	MAY	( mailLocalAddress $ mailHost $ mailRoutingAddress ) )

#-----------------------------------------------------------
# draft-srivastava-ldap-mail-00.txt !!!EXPIRED!!!
#	(a work in progress)
#
attributetype ( 1.3.6.1.4.1.42.2.27.2.1.15
	NAME 'rfc822MailMember'
	DESC 'rfc822 mail address of group member(s)'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

#-----------------------------------------------------------
# !!!no I-D!!!
#	(a work in progress)
#
objectclass ( 1.3.6.1.4.1.42.2.27.1.2.5
	NAME 'nisMailAlias'
	DESC 'NIS mail alias'
	SUP top STRUCTURAL
	MUST cn
	MAY rfc822MailMember )

Этот стандартный набор схемы данных распространяется с большинством дистрибутивов LDAP.

# $OpenLDAP: pkg/ldap/servers/slapd/schema/core.schema,
#  v 1.7.2.19 2002/06/06 00:25:24 kurt Exp $
#
# OpenLDAP Core schema
#
# Includes LDAPv3 schema items from:
#	RFC2251-RFC2256 (LDAPv3)
#
# select standard track schema items:
#	RFC2079 (URI)
#	RFC1274 (uid/dc)
#	RFC2247 (dc/dcObject)
#	RFC2589 (Dynamic Directory Services)
#
# select informational schema items:
#	RFC2377 (uidObject)
#
# select IETF ''work in progress'' LDAPext/LDUP items
#   ldapSubentry
#	ldapRootDSE
#	named referrals
#	alias draft

###########################################################################
#                                                                         #
## THESE ATTRIBUTES ARE OPERATIONAL FROM OpenLDAP 2.1+  AND NOT INCLUDED  #
## IN CORE.SCHEMA                                                         #
#                INCLUDED HERE FOR CLARITY ONLY                           #
###########################################################################

# Standard X.501(93) Operational Attribute Types from RFC2252
attributetype ( 2.5.4.41 NAME 'name'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

attributetype ( 2.5.4.49 NAME 'distinguishedName'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

# Standard attribute types from RFC2256

attributetype ( 2.5.4.0 NAME 'objectClass'
	EQUALITY objectIdentifierMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

attributetype ( 2.5.4.1 NAME 'aliasedObjectName'
	EQUALITY distinguishedNameMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )

########## END OF OPERATIONAL ATTRIBUTES ####################

attributetype ( 2.5.4.2 NAME 'knowledgeInformation'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) SUP name )

attributetype ( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )

# (2-letter code from ISO 3166)
attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) SUP name SINGLE-VALUE )

attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' ) SUP name )

attributetype ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' ) SUP name )

attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' )
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' ) SUP name )

attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) SUP name )

attributetype ( 2.5.4.12 NAME 'title' 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} )

# Obsoleted by enhancedSearchGuide
attributetype ( 2.5.4.14 NAME 'searchGuide'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )

attributetype ( 2.5.4.15 NAME 'businessCategory'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 2.5.4.16 NAME 'postalAddress'
	EQUALITY caseIgnoreListMatch
	SUBSTR caseIgnoreListSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

attributetype ( 2.5.4.17 NAME 'postalCode'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )

attributetype ( 2.5.4.18 NAME 'postOfficeBox'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )

attributetype ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 2.5.4.20 NAME 'telephoneNumber'
	EQUALITY telephoneNumberMatch
	SUBSTR telephoneNumberSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )

attributetype ( 2.5.4.21 NAME 'telexNumber'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )

attributetype ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )

attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )

attributetype ( 2.5.4.24 NAME 'x121Address'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )

attributetype ( 2.5.4.25 NAME 'internationaliSDNNumber'
	EQUALITY numericStringMatch
	SUBSTR numericStringSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )

attributetype ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

attributetype ( 2.5.4.27 NAME 'destinationIndicator'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )

attributetype ( 2.5.4.28 NAME 'preferredDeliveryMethod'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
	SINGLE-VALUE )

attributetype ( 2.5.4.29 NAME 'presentationAddress'
	EQUALITY presentationAddressMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.43
	SINGLE-VALUE )

attributetype ( 2.5.4.30 NAME 'supportedApplicationContext'
	EQUALITY objectIdentifierMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

attributetype ( 2.5.4.31 NAME 'member' SUP distinguishedName )

attributetype ( 2.5.4.32 NAME 'owner' SUP distinguishedName )

attributetype ( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName )

attributetype ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName )

attributetype ( 2.5.4.35 NAME 'userPassword'
	EQUALITY octetStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )

# Must be transferred using ;binary
attributetype ( 2.5.4.36 NAME 'userCertificate'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

# Must be transferred using ;binary
attributetype ( 2.5.4.37 NAME 'cACertificate'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

# Must be transferred using ;binary
attributetype ( 2.5.4.38 NAME 'authorityRevocationList'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

# Must be transferred using ;binary
attributetype ( 2.5.4.39 NAME 'certificateRevocationList'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

# Must be stored and requested in the binary form
attributetype ( 2.5.4.40 NAME 'crossCertificatePair'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )

attributetype ( 2.5.4.42 NAME ( 'givenName' 'gn' ) SUP name )

attributetype ( 2.5.4.43 NAME 'initials' SUP name
	DESC 'The initials attribute type contains the initials of some
		or all of an individuals names, but not the surname(s).' )

attributetype ( 2.5.4.44 NAME 'generationQualifier' 
	DESC 'e.g. Jr or II.'
	SUP name )

attributetype ( 2.5.4.45 NAME 'x500UniqueIdentifier'
	EQUALITY bitStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

attributetype ( 2.5.4.46 NAME 'dnQualifier'
	EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

attributetype ( 2.5.4.47 NAME 'enhancedSearchGuide'
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )

attributetype ( 2.5.4.48 NAME 'protocolInformation'
  EQUALITY protocolInformationMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )

# 2.5.4.49 is defined above as it's used for subtyping
#attributetype ( 2.5.4.49 NAME 'distinguishedName'
#	EQUALITY distinguishedNameMatch
#	SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

attributetype ( 2.5.4.50 NAME 'uniqueMember'
  EQUALITY uniqueMemberMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

attributetype ( 2.5.4.51 NAME 'houseIdentifier'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

# Must be transferred using ;binary
attributetype ( 2.5.4.52 NAME 'supportedAlgorithms'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )

# Must be transferred using ;binary
attributetype ( 2.5.4.53 NAME 'deltaRevocationList'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

attributetype ( 2.5.4.54 NAME 'dmdName' SUP name )

# Standard object classes from RFC2256

objectclass ( 2.5.6.0 NAME 'top' ABSTRACT
  MUST objectClass )

objectclass ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL
  MUST aliasedObjectName )

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL
  MUST c
  MAY ( searchGuide $ description ) )

objectclass ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL
  MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )

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 ) )

objectclass ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL
  MUST ou
  MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
   x121Address $ registeredAddress $ destinationIndicator $
   preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
   telephoneNumber $ internationaliSDNNumber $
   facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
   postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

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

objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
  MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $
   preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
   telephoneNumber $ internationaliSDNNumber $
   facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
   postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )

objectclass ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL
  MUST cn
  MAY ( x121Address $ registeredAddress $ destinationIndicator $
   preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
   telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
   seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
   postOfficeBox $ postalCode $ postalAddress $
   physicalDeliveryOfficeName $ ou $ st $ l $ description ) )

objectclass ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL
  MUST ( member $ cn )
  MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

objectclass ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL
  MUST l
  MAY ( businessCategory $ x121Address $ registeredAddress $
   destinationIndicator $ preferredDeliveryMethod $ telexNumber $
   teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $
   facsimileTelephoneNumber $ street $
   postOfficeBox $ postalCode $ postalAddress $
   physicalDeliveryOfficeName $ st $ l ) )

objectclass ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL
   MUST cn
   MAY ( seeAlso $ ou $ l $ description ) )

objectclass ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL
   MUST ( presentationAddress $ cn )
   MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
	description ) )

objectclass ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL
   MAY knowledgeInformation )

objectclass ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL
   MUST cn
   MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )

objectclass ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY
   MUST userCertificate )

objectclass ( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY
   MUST ( authorityRevocationList $ certificateRevocationList $
        cACertificate )
   MAY crossCertificatePair )

objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
   MUST ( uniqueMember $ cn )
   MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

objectclass ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY
   MAY ( supportedAlgorithms ) )

objectclass ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
    SUP certificationAuthority
   AUXILIARY MAY ( deltaRevocationList ) )

objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL
   MUST ( cn )
   MAY ( certificateRevocationList $ authorityRevocationList $
        deltaRevocationList ) )

objectclass ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL
   MUST ( dmdName )
   MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
    x121Address $ registeredAddress $ destinationIndicator $
    preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
    telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
    street $ postOfficeBox $ postalCode $ postalAddress $
    physicalDeliveryOfficeName $ st $ l $ description ) )
#
# adding extensibleClass allows the addition of any attribute to an entry
#
objectclass ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
   DESC 'RFC2252: extensible object'
   SUP top AUXILIARY )

#
# Standard Track URI label schema from RFC2079
#
attributetype ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI'
   DESC 'RFC2079: Uniform Resource Identifier with optional label'
   EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

objectclass ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject'
   DESC 'RFC2079: object that contains the URI attribute type'
   MAY ( labeledURI )
   SUP top AUXILIARY )

#
# Standard Track Dynamic Directory Services from RFC2589
#
objectclass ( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
   DESC 'RFC2589: Dynamic Object'
   SUP top AUXILIARY )

attributetype ( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
   DESC 'RFC2589: entry time-to-live'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
   NO-USER-MODIFICATION USAGE dSAOperation )

attributetype ( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees'
   DESC 'RFC2589: dynamic subtrees'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
   USAGE dSAOperation )

#
# Derived from RFC1274, but with new "short names"
#
attributetype ( 0.9.2342.19200300.100.1.1
   NAME ( 'uid' 'userid' )
   DESC 'RFC1274: user identifier'
   EQUALITY caseIgnoreMatch
   SUBSTR caseIgnoreSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

attributetype ( 0.9.2342.19200300.100.1.3
   NAME ( 'mail' 'rfc822Mailbox' )
   DESC 'RFC1274: RFC822 Mailbox'
   EQUALITY caseIgnoreIA5Match
   SUBSTR caseIgnoreIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
   DESC 'RFC1274: simple security object'
   SUP top AUXILIARY
   MUST userPassword )

# RFC1274 + RFC2247
attributetype ( 0.9.2342.19200300.100.1.25
   NAME ( 'dc' 'domainComponent' )
   DESC 'RFC1274/2247: domain component'
   EQUALITY caseIgnoreIA5Match
   SUBSTR caseIgnoreIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

# RFC2247
objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
   DESC 'RFC2247: domain component object'
   SUP top AUXILIARY MUST dc )


# From RFC2377
objectclass ( 1.3.6.1.1.3.1 NAME 'uidObject'
   DESC 'RFC2377: uid object'
   SUP top AUXILIARY MUST uid )

#
# From draft-zeilenga-ldap-nameref-xx.txt
#	used to represent referrals in the directory
#
attributetype ( 2.16.840.1.113730.3.1.34 NAME 'ref'
   DESC 'Named referral'
   EQUALITY caseExactMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   USAGE distributedOperation )

objectclass ( 2.16.840.1.113730.3.2.6 NAME 'referral'
   DESC 'Named referral object'
   SUP top STRUCTURAL MUST ref )

#
# LDAPsubEntry
#	deprecated!
objectclass ( 2.16.840.1.113719.2.142.6.1.1
   NAME 'LDAPsubEntry'
   DESC 'LDAP Subentry'
   SUP top STRUCTURAL MAY cn )

#
# OpenLDAProotDSE
#	likely to change!
objectclass ( 1.3.6.1.4.1.4203.1.4.1
   NAME ( 'OpenLDAProotDSE' 'LDAProotDSE' )
   DESC 'OpenLDAP Root DSE object'
   SUP top STRUCTURAL MAY cn )

#
# From Cosine Pilot
#
attributetype ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
   EQUALITY caseIgnoreIA5Match
   SUBSTR caseIgnoreIA5SubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

#
# From U-Mich
#
attributetype ( 1.3.6.1.4.1.250.1.32
   NAME ( 'krbName' 'kerberosName' )
   DESC 'Kerberos Name'
   EQUALITY caseIgnoreIA5Match
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
   SINGLE-VALUE )

#
# draft-zeilenga-ldap-features-xx.txt (supportedFeatures)
#
attributetype ( 1.3.6.1.4.1.4203.1.3.5
   NAME 'supportedFeatures'
   DESC 'features supported by the server'
   EQUALITY objectIdentifierMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
   USAGE dSAOperation )

#
# OpenLDAP specific schema items
#
attributetype ( 1.3.6.1.4.1.4203.1.3.1
   NAME 'entry'
   DESC 'OpenLDAP ACL entry pseudo-attribute'
   SYNTAX 1.3.6.1.4.1.4203.1.1.1
   SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )

attributetype ( 1.3.6.1.4.1.4203.1.3.2
   NAME 'children'
   DESC 'OpenLDAP ACL children pseudo-attribute'
   SYNTAX 1.3.6.1.4.1.4203.1.1.1
   SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )

# Experimental ( subject to change )
#	this really shouldn't be published!
attributetype ( 1.3.6.1.4.1.4203.666.1.5
   NAME 'OpenLDAPaci'
   DESC 'OpenLDAP access control information'
   EQUALITY OpenLDAPaciMatch
   SYNTAX 1.3.6.1.4.1.4203.666.2.1
   USAGE directoryOperation )

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# $OpenLDAP: pkg/ldap/servers/slapd/schema/nis.schema,
# v 1.1.8.5 2000/09/28 17:35:12 kurt Exp $
# Definitions from RFC2307 (Experimental)
#	An Approach for Using LDAP as a Network Information Service

# Depends upon core.schema and cosine.schema

# Note: The definitions in RFC2307 are given in syntaxes closely related
# to those in RFC2252, however, some liberties are taken that are not
# supported by RFC2252.  This file has been written following RFC2252
# strictly.

# OID Base is iso(1) org(3) dod(6) internet(1) directory(1) nisSchema(1).
# i.e. nisSchema in RFC2307 is 1.3.6.1.1.1
#
# Syntaxes are under 1.3.6.1.1.1.0 (two new syntaxes are defined)
#	validaters for these syntaxes are incomplete, they only
#	implement printable string validation (which is good as the
#	common use of these syntaxes violates the specification).
# Attribute types are under 1.3.6.1.1.1.1
# Object classes are under 1.3.6.1.1.1.2

# Attribute Type Definitions
attributetype ( 1.3.6.1.1.1.1.0 NAME 'uidNumber'
	DESC 'An integer uniquely identifying a user in an administrative domain'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.1 NAME 'gidNumber'
	DESC 'An integer uniquely identifying a group in an administrative domain'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos'
	DESC 'The GECOS field; the common name'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory'
	DESC 'The absolute path to the home directory'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.4 NAME 'loginShell'
	DESC 'The path to the login shell'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.6 NAME 'shadowMin'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.7 NAME 'shadowMax'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.12 NAME 'memberUid'
	EQUALITY caseExactIA5Match
	SUBSTR caseExactIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup'
	EQUALITY caseExactIA5Match
	SUBSTR caseExactIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
	DESC 'Netgroup triple'
	SYNTAX 1.3.6.1.1.1.0.0 )

attributetype ( 1.3.6.1.1.1.1.15 NAME 'ipServicePort'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.16 NAME 'ipServiceProtocol'
	SUP name )

attributetype ( 1.3.6.1.1.1.1.17 NAME 'ipProtocolNumber'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.18 NAME 'oncRpcNumber'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.19 NAME 'ipHostNumber'
	DESC 'IP address as a dotted decimal, eg. 192.168.1.1, omitting leading zeros'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )

attributetype ( 1.3.6.1.1.1.1.20 NAME 'ipNetworkNumber'
	DESC 'IP network as a dotted decimal, eg. 192.168, omitting leading zeros'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.21 NAME 'ipNetmaskNumber'
	DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, omitting leading zeros'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} SINGLE-VALUE )

attributetype ( 1.3.6.1.1.1.1.22 NAME 'macAddress'
	DESC 'MAC address in maximal, colon separated hex notation, eg. 00:00:92:90:ee:e2'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )

attributetype ( 1.3.6.1.1.1.1.23 NAME 'bootParameter'
	DESC 'rpc.bootparamd parameter'
	SYNTAX 1.3.6.1.1.1.0.1 )

attributetype ( 1.3.6.1.1.1.1.24 NAME 'bootFile'
	DESC 'Boot image name'
	EQUALITY caseExactIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.1.1.1.26 NAME 'nisMapName'
	SUP name )

attributetype ( 1.3.6.1.1.1.1.27 NAME 'nisMapEntry'
	EQUALITY caseExactIA5Match
	SUBSTR caseExactIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{1024} SINGLE-VALUE )

# Object Class Definitions

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
	DESC 'Abstraction of an account with POSIX attributes'
	MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
	MAY ( userPassword $ loginShell $ gecos $ description ) )

objectclass ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY
	DESC 'Additional attributes for shadow passwords'
	MUST uid
	MAY ( userPassword $ shadowLastChange $ shadowMin $
	      shadowMax $ shadowWarning $ shadowInactive $
	      shadowExpire $ shadowFlag $ description ) )

objectclass ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top STRUCTURAL
	DESC 'Abstraction of a group of accounts'
	MUST ( cn $ gidNumber )
	MAY ( userPassword $ memberUid $ description ) )

objectclass ( 1.3.6.1.1.1.2.3 NAME 'ipService' SUP top STRUCTURAL
	DESC 'Abstraction an Internet Protocol service.
	      Maps an IP port and protocol (such as tcp or udp)
	      to one or more names; the distinguished value of
	      the cn attribute denotes the service"s canonical
	      name'
	MUST ( cn $ ipServicePort $ ipServiceProtocol )
	MAY ( description ) )

objectclass ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
	DESC 'Abstraction of an IP protocol. Maps a protocol number
	      to one or more names. The distinguished value of the cn
	      attribute denotes the protocol"s canonical name'
	MUST ( cn $ ipProtocolNumber $ description )
	MAY description )

objectclass ( 1.3.6.1.1.1.2.5 NAME 'oncRpc' SUP top STRUCTURAL
	DESC 'Abstraction of an Open Network Computing (ONC)
	      [RFC1057] Remote Procedure Call (RPC) binding.
	      This class maps an ONC RPC number to a name.
	      The distinguished value of the cn attribute denotes
	      the RPC service"s canonical name'
	MUST ( cn $ oncRpcNumber $ description )
	MAY description )

objectclass ( 1.3.6.1.1.1.2.6 NAME 'ipHost' SUP top AUXILIARY
	DESC 'Abstraction of a host, an IP device. The distinguished
	      value of the cn attribute denotes the host"s canonical
	      name. Device SHOULD be used as a structural class'
	MUST ( cn $ ipHostNumber )
	MAY ( l $ description $ manager ) )

objectclass ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
	DESC 'Abstraction of a network. The distinguished value of
	      the cn attribute denotes the network"s canonical name'
	MUST ( cn $ ipNetworkNumber )
	MAY ( ipNetmaskNumber $ l $ description $ manager ) )

objectclass ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
	DESC 'Abstraction of a netgroup. May refer to other netgroups'
	MUST cn
	MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )

objectclass ( 1.3.6.1.1.1.2.9 NAME 'nisMap' SUP top STRUCTURAL
	DESC 'A generic abstraction of a NIS map'
	MUST nisMapName
	MAY description )

objectclass ( 1.3.6.1.1.1.2.10 NAME 'nisObject' SUP top STRUCTURAL
	DESC 'An entry in a NIS map'
	MUST ( cn $ nisMapEntry $ nisMapName )
	MAY description )

objectclass ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' SUP top AUXILIARY
	DESC 'A device with a MAC address; device SHOULD be
	      used as a structural class'
	MAY macAddress )

objectclass ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' SUP top AUXILIARY
	DESC 'A device with boot parameters; device SHOULD be
	      used as a structural class'
	MAY ( bootFile $ bootParameter ) )

Этот набор схемы данных распространяется со стандартным дистрибутивом OpenLDAP.

# $OpenLDAP: pkg/ldap/servers/slapd/schema/inetorgperson.schema,
# v 1.4.2.6 2001/10/09 17:15:08 kurt Exp $
#
# InetOrgPerson (RFC2798)
#
# Depends upon
#   Definition of an X.500 Attribute Type and an Object Class to Hold
#   Uniform Resource Identifiers (URIs) [RFC2079]
#	(core.schema)
#   
#   A Summary of the X.500(96) User Schema for use with LDAPv3 [RFC2256]
#	(core.schema)
#
#   The COSINE and Internet X.500 Schema [RFC1274] (cosine.schema)
   
# carLicense
# This multivalued field is used to record the values of the license or
# registration plate associated with an individual.
attributetype ( 2.16.840.1.113730.3.1.1
   NAME 'carLicense'
   DESC 'RFC2798: vehicle license or registration plate'
   EQUALITY caseIgnoreMatch
   SUBSTR caseIgnoreSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# departmentNumber
# Code for department to which a person belongs.  This can also be
# strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123).
attributetype ( 2.16.840.1.113730.3.1.2
   NAME 'departmentNumber'
   DESC 'RFC2798: identifies a department within an organization'
   EQUALITY caseIgnoreMatch
   SUBSTR caseIgnoreSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# displayName
# When displaying an entry, especially within a one-line summary list, it
# is useful to be able to identify a name to be used.  Since other attri-
# bute types such as 'cn' are multivalued, an additional attribute type is
# needed.  Display name is defined for this purpose.
attributetype ( 2.16.840.1.113730.3.1.241
   NAME 'displayName'
   DESC 'RFC2798: preferred name to be used when displaying entries'
   EQUALITY caseIgnoreMatch
   SUBSTR caseIgnoreSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   SINGLE-VALUE )

# employeeNumber
# Numeric or alphanumeric identifier assigned to a person, typically based
# on order of hire or association with an organization.  Single valued.
attributetype ( 2.16.840.1.113730.3.1.3
   NAME 'employeeNumber'
   DESC 'RFC2798: numerically identifies an employee within an organization'
   EQUALITY caseIgnoreMatch
   SUBSTR caseIgnoreSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   SINGLE-VALUE )

# employeeType
# Used to identify the employer to employee relationship.  Typical values
# used will be "Contractor", "Employee", "Intern", "Temp", "External", and
# "Unknown" but any value may be used.
attributetype ( 2.16.840.1.113730.3.1.4
   NAME 'employeeType'
   DESC 'RFC2798: type of employment for a person'
   EQUALITY caseIgnoreMatch
   SUBSTR caseIgnoreSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# jpegPhoto
# Used to store one or more images of a person using the JPEG File
# Interchange Format [JFIF].
# Note that the jpegPhoto attribute type was defined for use in the
# Internet X.500 pilots but no referencable definition for it could be
# located.    
attributetype ( 0.9.2342.19200300.100.1.60
   NAME 'jpegPhoto'
   DESC 'a JPEG image'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )

# preferredLanguage
# Used to indicate an individual's preferred written or spoken
# language.  This is useful for international correspondence or human-
# computer interaction.  Values for this attribute type MUST conform to
# the definition of the Accept-Language header field defined in
# [RFC2068] with one exception:  the sequence "Accept-Language" ":"
# should be omitted.  This is a single valued attribute type.
attributetype ( 2.16.840.1.113730.3.1.39
   NAME 'preferredLanguage'
   DESC 'RFC2798: preferred written or spoken language for a person'
   EQUALITY caseIgnoreMatch
   SUBSTR caseIgnoreSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   SINGLE-VALUE )

# userSMIMECertificate
# A PKCS#7 [RFC2315] SignedData, where the content that is signed is
# ignored by consumers of userSMIMECertificate values.  It is
# recommended that values have a `contentType' of data with an absent
# `content' field.  Values of this attribute contain a person's entire
# certificate chain and an smimeCapabilities field [RFC2633] that at a
# minimum describes their SMIME algorithm capabilities.  Values for
# this attribute are to be stored and requested in binary form, as
# 'userSMIMECertificate;binary'.  If available, this attribute is
# preferred over the userCertificate attribute for S/MIME applications.
## OpenLDAP note: ";binary" transfer should NOT be used as syntax is binary
attributetype ( 2.16.840.1.113730.3.1.40
   NAME 'userSMIMECertificate'
   DESC 'RFC2798: PKCS#7 SignedData used to support S/MIME'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )

# userPKCS12
# PKCS #12 [PKCS12] provides a format for exchange of personal identity
# information.  When such information is stored in a directory service,
# the userPKCS12 attribute should be used. This attribute is to be stored
# and requested in binary form, as 'userPKCS12;binary'.  The attribute
# values are PFX PDUs stored as binary data.
## OpenLDAP note: ";binary" transfer should NOT be used as syntax is binary
attributetype ( 2.16.840.1.113730.3.1.216
   NAME 'userPKCS12'
   DESC 'RFC2798: PKCS #12 PFX PDU for exchange of personal identity information'
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )


# inetOrgPerson
# The inetOrgPerson represents people who are associated with an
# organization in some way.  It is a structural class and is derived
# from the organizationalPerson which is defined in X.521 [X521].
objectclass ( 2.16.840.1.113730.3.2.2
   NAME 'inetOrgPerson'
   DESC 'RFC2798: Internet Organizational Person'
   SUP organizationalPerson
   STRUCTURAL
   MAY ( audio $ businessCategory $ carLicense $ departmentNumber $
    displayName $ employeeNumber $ employeeType $ givenName $
    homePhone $ homePostalAddress $ initials $ jpegPhoto $
    labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $
    roomNumber $ secretary $ uid $ userCertificate $
    x500uniqueIdentifier $ preferredLanguage $
    userSMIMECertificate $ userPKCS12 )
   )  

Этот набор схемы данных распространяется со стандартным дистрибутивом Courier-MTA и Courier-IMAP (in src/courier-0.xx/authldap.schema).

#$Id: authldap.schema,v 1.5 2004/04/18 15:54:38 mrsam Exp $
#
# OID prefix: 1.3.6.1.4.1.10018
#
# Attributes: 1.3.6.1.4.1.10018.1.1
#
# Depends on: nis.schema, which depends on cosine.schema

attributetype ( 1.3.6.1.4.1.10018.1.1.1 NAME 'mailbox'
	DESC 'The absolute path to the mailbox for a mail account in a non-default location'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.10018.1.1.2 NAME 'quota'
	DESC 'A string that represents the quota on a mailbox'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.10018.1.1.3 NAME 'clearPassword'
	DESC 'A separate text that stores the mail account password in clear text'
        EQUALITY octetStringMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128})

attributetype ( 1.3.6.1.4.1.10018.1.1.4 NAME 'maildrop'
        DESC 'RFC822 Mailbox - mail alias'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

attributetype ( 1.3.6.1.4.1.10018.1.1.5 NAME 'mailsource'
        DESC 'Message source'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.10018.1.1.6 NAME 'virtualdomain'
        DESC 'A mail domain that is mapped to a single mail account'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.10018.1.1.7 NAME 'virtualdomainuser'
        DESC 'Mailbox that receives mail for a mail domain'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.10018.1.1.8 NAME 'defaultdelivery'
        DESC 'Default mail delivery instructions'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

#
# Objects: 1.3.6.1.4.1.10018.1.2
#

objectclass ( 1.3.6.1.4.1.10018.1.2.1 NAME 'CourierMailAccount' SUP top AUXILIARY
  DESC 'Mail account object as used by the Courier mail server'
  MUST ( mail $ homeDirectory $ uidNumber $ gidNumber )
  MAY ( mailbox $ uid $ cn $ gecos $ description $ loginShell $ quota $
        userPassword $ clearPassword $ defaultdelivery) )

objectclass ( 1.3.6.1.4.1.10018.1.2.2 NAME 'CourierMailAlias' SUP top AUXILIARY
  DESC 'Mail aliasing/forwarding entry'
  MUST ( mail $ maildrop )
  MAY ( mailsource $ description ) )

objectclass ( 1.3.6.1.4.1.10018.1.2.3 NAME 'CourierDomainAlias' SUP top AUXILIARY
  DESC 'Domain mail aliasing/forwarding entry'
  MUST ( virtualdomain $ virtualdomainuser )
  MAY ( mailsource $ description ) )

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!