Глава 3. Схема данных, объектные классы и атрибуты LDAP

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

LDAP и X.500 имеют много общих терминов, некоторые из них важны, некоторые — просто ерунда.

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

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

Когда Вы создаёте запись в DIT, составляющие её данные содержатся в атрибутах, которые сгруппированы в объектные классы, которые в свою очередь упакованы в наборы схемы данных.

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

Медленно но верно мы делаем стандартные наборы схемы данных доступными для просмотра. Если бы мы были поумнее и у нас было побольше времени, мы бы переделали это с использованием htags и gtags. Но, к сожалению, с умом и временем как-то не задалось...

Содержание

3.1 Обзор элементов LDAP
3.2 Наборы схемы данных
3.3 Объектные классы
3.4 Атрибуты
3.5 Правила соответствия
3.6 Операционные атрибуты и объекты LDAP

3.1 Обзор элементов LDAP

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

Ниже определены важные правила, относящиеся к каждой из этих 'фенечек':

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

    • Все объектные классы и атрибуты определяются внутри набора схемы (существует некоторое количество так называемых операционных объектных классов и атрибутов, которые встроены в программное обеспечение LDAP-сервера и не требуют внешнего определения, но пока мы их просто проигнорируем).

    • Все наборы схемы, включающие используемые в какой-либо реализации LDAP объектные классы и атрибуты, должны быть известны LDAP-серверу (в OpenLDAP, при использовании OLC (cn=config), наборы схемы могут быть подключены сразу при инсталляции ("из коробки"), а также добавлены с помощью этой процедуры, а при использовании конфигурационного файла slapd.conf — с помощью директивы include).

    • Атрибут, определённый в одном наборе схемы, может использоваться в объектном классе, определённом в другом наборе схемы — стиль Pick'n Mix.

  2. В объектных классах сгруппированы наборы атрибутов:

    • Объектные классы определяются внутри наборов схемы.

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

    • Объектные классы могут быть структурными (STRUCTURAL), в этом случае они могут использоваться для создания записей (объектов данных), вспомогательными (AUXILIARY), в этом случае они могут быть добавлены в любую подходящую запись, или абстрактными (ABSTRACT)  — несуществующая 'фенечка'. Чаще всего встречается абстрактный объектный класс top, формирующий самый верхний уровень любой иерархии объектных классов и ограничивающий любую иерархию.

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

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

    • Объектные классы определяют, является ли атрибут обязательным (MUST), то есть должен присутствовать в записи, либо необязательным (MAY), то есть может присутствовать в записи с данным объектным классом.

    • Объектные классы определяются с помощью нотации ASN.1.

  3. Атрибуты обычно содержат данные:

    • Каждый атрибут определён в наборе схемы данных.

    • Каждый атрибут входит в один или несколько объектных классов.

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

    • Характеристики атрибута определяются с помощью нотации ASN.1.

    • Атрибут может появляться лишь однажды в любом экземпляре содержащего его объектного класса (SINGLE-VALUE), либо может появляться более одного раза в любом экземпляре содержащего его объектного класса (MULTI-VALUE). Значение по умолчанию — MULTI-VALUE. Так, например, вполне разумно иметь несколько адресов электронной почты (атрибут mail), зато иметь более одного пароля (атрибут userPassword) — повод для путаницы. Не каждому под силу будет разобраться, что тут к чему.

    • Определение атрибута может быть частью иерархии, в этом случае оно наследует все свойства своих родителей. Например, commonName (cn), givenName (gn) и surname (sn) являются потомками атрибута name. В отличие от объектных классов, иерархии атрибутов не завершаются эквивалентом top. В случае атрибутов, отсутствие в определении атрибута указания вышестоящего (SUP) атрибута говорит, как ни странно, о том, что это и есть конец иерархии.

    • Определение атрибута включает его тип или синтаксис (SYNTAX), например, строка или число. Кроме того, с помощью так называемых правил соответствия (matchingRules), указывается то, как атрибут будет вести себя в определённых условиях, например, будет ли при операциях сравнения учитываться регистр символов или нет. Подробнее об этом позже, значительно позже.

  4. В записях в пределах DIT сгруппированы наборы объектных классов:

    • Записи должны содержать один и только один структурный объектный класс. У структурного объектного класса может быть вышестоящий объектный класс, тоже являющийся структурным. То есть структурный объектный класс может быть частью иерархии и такая иерархия может быть представлена как единый структурный объектный класс.

    • Записи могут содержать любое количество вспомогательных объектных классов.

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

    • У записи могут быть родительские записи, располагающиеся выше неё в иерархии адресов (иерархии именования).

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

Диаграмма, иллюстрирующая некоторые из этих отношений:

LDAP — иерархия объектных классов и атрибутов

Наверх

3.2 Наборы схемы данных LDAP

Наборы схемы данных LDAP — не более чем удобная упаковка для содержания во многом схожих объектных классов и атрибутов.

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

Основное правило: Каждый используемый в реализации LDAP атрибут или объектный класс, включая их вышестоящие объектные классы или атрибуты, должен быть определен в наборе схемы, и этот набор схемы должен быть известен серверу LDAP. В OpenLDAP с конфигурацией OLC (cn=config) установленные наборы схемы располагаются в ветке cn=schema,cn=config; дополнительные наборы схемы можно установить с помощью этой процедуры. При использовании конфигурационного файла slapd.conf серверу сообщают о наборах схемы с помощью директивы include.

Диаграмма, иллюстрирующая использование наборов схемы как упаковочных единиц:

Наборы схемы данных, объектные классы и атрибуты LDAP

Наверх

3.3 Объектные классы LDAP

Объектный класс — это коллекция атрибутов (или контейнер атрибутов). У него следующие характеристики:

  1. Объектный класс определяется внутри набора схемы.

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

  3. Объектный класс имеет глобальное уникальное имя или идентификатор.

  4. Объектный класс, поскольку является контейнером атрибутов, также сам по себе атрибут и может фигурировать в операциях поиска.

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

  6. В записи LDAP должны присутствовать один или несколько объектных классов.

  7. В записи LDAP должен присутствовать один и только один структурный (STRUCTURAL) объектный класс.

  8. Все объектные классы, поддерживаемые сервером LDAP, формируют коллекцию под названием objectclasses, просмотреть которую можно через subschema.

Определение объектного класса

Формальное определение объектного класса дано в разделе 4.4 RFC 2252 и выглядит так:

ObjectClassDescription = "(" whsp
 numericoid whsp      ; идентификатор объектного класса
 [ "NAME" qdescrs ]
 [ "DESC" qdstring ]
 [ "OBSOLETE" whsp ]
 [ "SUP" oids ]       ; вышестоящий объектный класс
 [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
                      ; по умолчанию структурный
 [ "MUST" oids ]      ; типы атрибутов
 [ "MAY" oids ]       ; типы атрибутов
  whsp ")"

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

Объектный класс определяется с помощью нотации ASN.1. Далее рассмотрим определение простого стандартного объектного класса country, взятого из набора схемы core.schema, поставляемого с дистрибутивами OpenLDAP.

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

Давайте разберём это определение:

Ключевое слово objectclass указывает, что это определение объектного класса. Как видите, всё не так уж сложно!

2.5.6.2 NAME 'country' определяет глобально уникальное имя данного объектного класса, состоящее из двух частей: NAME 'country' просто позволяет обращаться к этому объектному классу с помощью некоего полупонятного текста — в данном случае английское слово country. Глобально уникальная часть определяется с помощью 2.5.6.2, так называемого OID (ObjectIdentifier, идентификатора объекта). OID 2.5.6.2, похоже, третий из объектных классов, когда-либо определённых X.500 (это следует из того факта, что 2.5.6 определяет совместные объектные классы itu-iso x.500, а последняя 2 — порядковый номер в пределах этого семейства OID). Не важно, какая организация присваивает этот номер, но он должен быть УНИКАЛЬНЫМ. Получение корпоративного OID (формально Private Enterprise Number (PEN)), позволяющего определять свои собственные атрибуты и объектные классы, — простая и бесплатная процедура, которую предоставляет IANA. Повторно использовать существующие OID — очень скверная штука (VERY BAD THING™).

SUP 'top' указывает, что у этого объектного класса есть РОДИТЕЛЬСКИЙ (или ВЫШЕСТОЯЩИЙ) объектный класс, то есть он является частью иерархии. В данном случае родительским объектным классом будет top — специальный (абстрактный) объектный класс, который ограничивает все объектные классы (является самым высоким уровнем). Объектный класс может иметь один или несколько родительских объектных классов.

Ключевое слово STRUCTURAL (структурный) указывает, что этот объектный класс содержит атрибуты и может формировать запись в DIT. В записи может быть только один структурный объектный класс, но структурный объектный класс может быть частью иерархии (то есть иметь другой структурный объектный класс (или классы) в качестве вышестоящего). (Дополнительная информация о структурных иерархиях и наследовании). Объектные классы также могут быть абстрактными (ABSTRACT), что указывает на несуществующий объектный класс, используемый для удобства. Наиболее часто используемый абстрактный объектный класс — это top, просто ограничивающий иерархию объектных классов. Наконец, объектный класс может быть вспомогательным (AUXILIARY), что говорит о том, что он содержит атрибуты и может использоваться для формирования записи с любым структурным объектным классом, но самостоятельно формировать запись в DIT не может. Во всех записях должен один (и только один) структурный объектный класс.

DESC 'описание'. Ну ладно, мы выбрали неудачный пример, где нет оператора DESC — зато определение объектного класса получилось коротким. DESC — это необязательное значение, предоставляющее текстовое описание порядка использования или содержимого объектного класса. Оно предназначено для чтения людьми и другого применения не имеет. Вот на что стало бы похоже country, если бы в него включили осмысленный оператор DESC:

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL
  DESC '2 character iso 3611 assigned country code'
  MUST c
  MAY ( searchGuide $ description ) )

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

MUST c. MUST указывает, что атрибуты из следующего за этим оператором списка являются обязательными. В данном случае атрибут c (c или countryName) должен присутствовать, иначе не создастся экземпляр объектного класса (с выдачей сообщения об ужасной ошибке) и, если это структурный (STRUCTURAL) объектный класс, запись не будет создана (сообщение об ошибке будет ещё более ужасным). Единичные значения записываются как было показано, несколько атрибутов заключаются в круглые скобки и разделяются знаком $ (доллар), вот так: ( attr1 $ attr2 $ attrn). Если у объектного класса нет обязательных (MUST) атрибутов, эта секция не включается.

MAY ( searchGuide $ description ) MAY указывает, что атрибуты из следующего за этим оператором списка являются необязательными и для создания экземпляра объектного класса их присутствие не требуется. Несколько значений записываются как было показано, а для единичного атрибута круглые скобки не нужны (синтаксис указания единичного атрибута смотрите выше в описании обязательных атрибутов). Если у объектного класса нет необязательных (MAY) атрибутов, эта секция не включается.

Ещё несколько примеров объектных классов

Вот как определяется объектный класс top:

objectclass ( 2.5.6.0 NAME 'top' ABSTRACT
	MUST objectClass )

Здесь демонстрируется использование оператора ABSTRACT в объектном классе. Поскольку top всегда находится в вершине иерархии, очевидно, что в его определении не может быть оператора SUP. OID также из присвоенных группе стандартизации X.500.

Авторы в многих документах настаивают, чтобы объектный класс top включался в файлы LDIF — на самом деле это не всегда необходимо.

Вот как определяется объектный класс dcObject:

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

Данный пример демонстрирует использование оператора AUXILIARY. Невозможно создать запись только на основе вспомогательного объектного класса. В этом примере OID показывает использование private enterprise OID (OID из пространства частного предприятия). Следующий фрагмент демонстрирует довольно типичное определение базового DN с использованием dcObject:

dn: dc=example,dc=com
dc: example.com
objectclass: dcObject
objectclass: organization
o: Example, Inc.

Данная запись создаётся объектным классом objectclass: organization (структурный объектный класс). dcObject идёт прицепом к этому объектному классу.

В следующем примере определяется объектный класс pilotOrganization и демонстрируется, что у объектного класса может быть один или несколько вышестоящих (родительских) объектных классов (в данном примере родительскими являются organization и organizationalUnit), в этом случае потомки наследуют свойства ВСЕХ родителей (чем-то похоже на людей, не правда ли?):

objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'
  SUP ( organization $ organizationalUnit ) STRUCTURAL
  MAY buildingName )

Дополнительная информация по наследованию в LDAP.

Мы пропустили объяснение оператора OBSOLETE (устаревший). Если он присутствует в определении объектного класса, это означает, что объектный класс использовать не нужно (хм!).

Наверх

3.4 Атрибуты LDAP

Атрибуты обычно содержат данные и имеют следующие характеристики:

  1. Каждый атрибут определён в наборе схемы данных.

  2. Каждый атрибут входит в один или несколько объектных классов.

  3. objectclass также является атрибутом и может использоваться в операциях поиска.

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

  5. Характеристики атрибута определяются с помощью нотации ASN.1.

  6. Атрибут может появляться лишь однажды в любом экземпляре содержащего его объектного класса (SINGLE-VALUE), либо может появляться более одного раза в любом экземпляре содержащего его объектного класса (MULTI-VALUE). Значение по умолчанию — MULTI-VALUE.

  7. Определение атрибута может быть частью иерархии, в этом случае оно наследует все свойства своих родителей. Например, commonName (cn), givenName (gn), surname (sn) являются потомками атрибута name.

  8. Определение атрибута включает его тип или синтаксис (SYNTAX), например, строка или число, а также как он будет вести себя в определённых условиях; например, будет ли при операциях сравнения учитываться регистр символов или нет.

  9. Атрибуты, поддерживаемые сервером LDAP, формируют коллекцию под названием attributetypes, просмотреть которую можно через subschema.

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

Формальное определение атрибута дано в разделе 4.4 RFC 2252 и выглядит так:

AttributeTypeDescription = "(" whsp
   numericoid whsp     ; идентификатор типа атрибута
 [ "NAME" qdescrs ]             ; имя, используемое в типе атрибута
 [ "DESC" qdstring ]            ; описание
 [ "OBSOLETE" whsp ]
 [ "SUP" woid ]                 ; происходит от этого
                                ; типа атрибута
 [ "EQUALITY" woid              ; имя правила соответствия
 [ "ORDERING" woid              ; имя правила соответствия
 [ "SUBSTR" woid ]              ; имя правила соответствия
 [ "SYNTAX" whsp noidlen whsp ] ; OID синтаксиса
 [ "SINGLE-VALUE" whsp ]        ; по умолчанию multi-valued
 [ "COLLECTIVE" whsp ]          ; по умолчанию not collective
 [ "NO-USER-MODIFICATION" whsp ]; по умолчанию user modifiable
 [ X-ORDERED whsp type ]        ; non-standard - default not X-ORDERED
 [ "USAGE" whsp AttributeUsage ]; по умолчанию userApplications
 whsp ")"

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

Атрибуты определяются с помощью нотаций ASN.1. Далее рассмотрим определение простого стандартного атрибута commonName (cn), взятого из набора схемы core.schema, поставляемого с дистрибутивами OpenLDAP.

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

Давайте разберём это определение:

attributetype указывает, что это определение атрибута — кто бы мог подумать! Мы, признаться, не сразу догадались.

2.5.4.3 NAME ('cn' 'commonName') определяет глобально уникальное имя для этого атрибута и состоит из двух значений в скобках: NAME ('cn' 'commonName'). Это позволяет Вам обращаться к этому атрибуту с помощью некоего полупонятного текста — в данном случае либо английское слово commonName, либо сокращение (псевдоним) cn. В принципе, нет ограничений на количество сокращений или псевдонимов, которые Вы можете иметь, лишь бы они были уникальными. В данной форме записи с несколькими именами эти имена заключаются в круглые скобки и разделяются пробелом. Так как cn появляется первым, он называется первичным (primary) именем, что очень важно, когда речь заходит об индексировании записей для оптимизации поиска.

Глобально уникальная часть определяется с помощью 2.5.4.3, так называемого OID (ObjectIdentifier, идентификатора объекта). OID 2.5.4.3 возможно, четвёртый из атрибутов, когда-либо определённых X.500 (2.5.4 означает, что это совместные типы атрибутов itu-iso x.500, последняя 3 — порядковый номер в пределах этого семейства OID). Не важно, какая организация присваивает этот номер, но он должен быть УНИКАЛЬНЫМ. Получение организацией OID, позволяющего определять свои собственные атрибуты и объектные классы, — простая процедура, которую предоставляет IANA. Повторно использовать существующие OID — очень скверная штука (EXTREMELY BAD THING™).

SUP 'name' указывает, что у этого атрибута есть РОДИТЕЛЬСКИЙ (или ВЫШЕСТОЯЩИЙ) атрибут, то есть он является частью иерархии. В данном случае родительским атрибутом будет name, который мы сейчас рассмотрим подробно, поскольку, если Вы помните, атрибут-потомок всегда наследует свойства родительского (или вышестоящего) атрибута (и может иметь свои дополнительные свойства). В операторе SUP может использоваться либо 'name', либо OID. Определения SUP 'name' и SUP 2.5.4.41 означают одно и то же, — но только не для того несчастного, который пытается в это разобраться, — и могут быть взаимозаменяемыми.

Вот определение атрибута name, это гораздо более серьёзное определение атрибута, являющегося вышестоящим (родительским) по отношению к приведённому выше атрибуту cn:

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.41 NAME 'name' определяет глобально уникальное имя для данного атрибута и, как и прежде, состоит из двух частей: NAME 'name' просто позволяет обращаться к этому атрибуту с помощью некоего полупонятного текста, и OID 2.5.4.41 указывает, что данный атрибут определён группой стандартизации X.500. Данный формат используется, поскольку здесь только одно значение имени, его не требуется заключать в круглые скобки как в приведённом выше примере с commonName.

EQUALITY caseIgnoreMatch указывает, как данный атрибут (и все его потомки) будут себя вести при использовании в поисковом фильтре, таком как (cn=jimbob) (cn потомок name), где не используется поисковых шаблонов. В данном случае определяется, что соответствие будет искаться без учёта регистра символов. caseIgnoreMatch — это правило соответствия, которое определяется в subschema.

SUBSTR caseIgnoreSubstringsMatch указывает, как данный атрибут (и все его потомки) будут себя вести при использовании в поисковом фильтре, использующем подстроки, например, (cn=jim*) (cn потомок name), и содержащем один или несколько поисковых шаблонов. В данном случае определяется, что соответствие будет искаться без учёта регистра символов. caseIgnoreSubstringMatch — это снова правило соответствия, которое определяется в subschema.

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} — это OID, определяющий тип данных, а также какие правила (проверки данных) применяются к этим данным. Полный список приведён в разделе 4.3.2 RFC 2252. В данном случае OID указывает, что это будет тип Directory String, определённый в в разделе 6.10 RFC 2252, и данные будут из набора символов ISO 10646 в форме UTF-8. Значение {32768} указывает максимальную длину строки и не является обязательным. Дополнительная информация по типам данных LDAP.

Другие характеристики

SINGLE-VALUE. Пропуск этого оператора означает, что данный атрибут multi-value, то есть он может появляться более одного раза в объектном классе или записи. Если какой-то атрибут может принимать только одно значение, это должно быть явно указано, как в определении атрибута dc ниже:

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 )

USAGE 'AttributeUsage'. По умолчанию — userApplication (или пользовательский атрибут), будет возвращён, если при поиске в списке атрибутов есть значение *. Если же значение данного оператора — dSAOperation, тогда этот атрибут будет операционным (возвращается, если при поиске в списке атрибутов есть значение +).

ORDERING 'matchingrule' указывается редко и используется для определения сопоставлений — лексикографического порядка сортировки (позволяет выполнять поиск с использованием <= и >=). Пример определения атрибута с указанием правила сортировки:

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 )

Дополнительные элементы определения:

Большинство читателей могут, к счастью, пропустить данные замечания. Они приводятся здесь только для тех, кто копается в недрах OpenLDAP или пытается разобраться, что означают все эти {}, то и дело встречающиеся при работе с системой конфигурации времени исполнения OpenLDAP (OLC cn=config).

  1. 'X-ORDERED type' — нестандартный элемент (в настоящее время определённый только в draft-chu-ldap-xordered-00, да и то не полностью), широко применяемый в системе OLC (cn=config) OpenLDAP. Наличие данного элемента в определении атрибута позволяет пользоваться упорядоченными множествами.

  2. type может быть либо 'VALUES', либо 'SIBLINGS'.

  3. 'VALUES' используется только с атрибутами MULTI-VALUE и указывает на то, что каждый атрибут будет иметь порядковый элемент в форме {x}, добавляемый в начало значения данного атрибута (и становящийся частью этого значения), где x — число, означающее порядковый номер и начинающееся с 0. Это позволяет при обращении к атрибутам с несколькими значениями явно указывать то значение, к которому мы хотим обратиться (для операций модификации или удаления), а при добавлении новых значений атрибута, для которых важен порядок их указания (например, при составлении ACL/ACP с помощью атрибута olcAccess), явно указать место его нахождения в упорядоченном множестве.

  4. 'SIBLINGS' используется только с атрибутами SINGLE-VALUE. Если атрибут с таким значением присутствует в записи, это говорит о том, что её непосредственные дочерние записи (только на один уровень ниже) должны иметь порядковое значение {x} в своих DN. Данный префикс с порядковым значением может быть указан явно при добавлении дочерней записи, либо, если таковой отсутствует, в качестве него будет назначено значение следующего порядкового номера, начиная с 0.

Наверх

3.5 Правила соответствия

Правила соответствия — часть так называемых операционных характеристик сервера LDAP.

Правила соответствия определяют методы сравнения, доступные в сервере LDAP:

  1. Правила соответствия обычно встроены в сервер LDAP и не требуют явного указания.
  2. Правила соответствия формируют коллекцию под названием matchingrules, просмотреть которую можно через subschema.
  3. Правило соответствия определяется для каждого атрибута с помощью операторов EQUALITY, SUBSTR и ORDERING по мере необходимости — то есть определяются только те свойства, которые требуются. Так, если атрибут не будет поддерживать использование шаблонов при поиске, свойство SUBSTR определять не нужно.

3.5.1 Определение правила соответствия

Большинство правил соответствия встроены, и Вам почти никогда не придётся определять их, но, как и у всего в LDAP, у них есть синтаксис определения. Вот пример определения правила соответствия caseIgnoreMatch:

matchingRule ( 2.5.13.2 NAME 'caseIgnoreMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

В результате разбора увидим следующее:

matchingrule указывает начало определения правила соответствия.

2.5.13.2 NAME 'caseIgnoreMatch' указывает глобально уникальное имя для данного правила соответствия и всегда состоит из двух частей: NAME 'caseIgnoreMatch' позволяет обращаться к этому правилу соответствия с помощью некоего полупонятного текста, и OID 2.5.13.2 указывает, что данное правило соответствия определено группой стандартизации X.500. Описание правила:

"Правило Case Ignore Match сравнивает совпадение предоставленной строки со значением атрибута типов PrintableString, NumericString, TeletexString, BMPString, UniversalString или DirectoryString без учета регистра (верхнего или нижнего) символов строки (например, "Dundee" и "DUNDEE" совпадают).

Правило возвращает TRUE, если строки имеют одинаковую длину и соответствующие символы идентичны, кроме возможного расхождения регистра символов.

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 указывает, что данное правило соответствия применяется к определённым типам, в данном случае к DirectoryString (строка в формате UTF-8).

Правила соответствия, встроенные в OpenLDAP

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

ldapsearch -H ldap://ldap.example.com -x -s base -b "cn=subschema"
  "(objectclass=*)" matchingrules
# matchingrules можно заменить на 
# attributetypes, objectclasses и другое.

Приведённая команда должна записываться в одну строку — она разделена только по соображениям форматирования HTML. Замените ldap.example.com на имя хоста Вашего LDAP-сервера. Если Вы выполняете команду на том же сервере, где запущен LDAP-сервер, можно опустить аргумент -H (значение по умолчанию которого — localhost).

В качестве альтернативы можно использовать любой LDAP-браузер по Вашему вкусу, указывая в качестве базового DN "cn=subschema".

Приведенная выше команда возвращает что-то вроде этого:

# Subschema
dn: cn=Subschema
matchingRules: ( 2.5.13.0 NAME 'objectIdentifierMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
matchingRules: ( 2.5.13.1 NAME 'distinguishedNameMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
matchingRules: ( 2.5.13.2 NAME 'caseIgnoreMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
matchingRules: ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
matchingRules: ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
matchingRules: ( 2.5.13.5 NAME 'caseExactMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
matchingRules: ( 2.5.13.6 NAME 'caseExactOrderingMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
matchingRules: ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
matchingRules: ( 2.5.13.8 NAME 'numericStringMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
matchingRules: ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
matchingRules: ( 2.5.13.13 NAME 'booleanMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
matchingRules: ( 2.5.13.14 NAME 'integerMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
matchingRules: ( 2.5.13.15 NAME 'integerOrderingMatch' 
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
matchingRules: ( 2.5.13.16 NAME 'bitStringMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
matchingRules: ( 2.5.13.17 NAME 'octetStringMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
matchingRules: ( 2.5.13.18 NAME 'octetStringOrderingMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
matchingRules: ( 2.5.13.20 NAME 'telephoneNumberMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
matchingRules: ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
matchingRules: ( 2.5.13.23 NAME 'uniqueMemberMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
matchingRules: ( 2.5.13.27 NAME 'generalizedTimeMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
matchingRules: ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
matchingRules: ( 2.5.13.29 NAME 'integerFirstComponentMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
matchingRules: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
matchingRules: ( 2.5.13.34 NAME 'certificateExactMatch'
  SYNTAX 1.2.826.0.1.3344810.7.1 )
matchingRules: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
matchingRules: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
matchingRules: ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
matchingRules: ( 1.3.6.1.4.1.4203.1.2.1 NAME 'caseExactIA5SubstringsMatch' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
matchingRules: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
matchingRules: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

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

Наверх

3.6 Операционные атрибуты и объекты LDAP

Есть куча встроенных в LDAP-сервер атрибутов и объектных классов, управляющих тем, как этот сервер функционирует. Такие атрибуты и объектные классы обычно называются операционными.

Эти операционные элементы располагаются в rootDSE и при обычных операциях не видны.

Здесь показаны отношения между DIT и входящими в них записями, а также RootDSE (Root Directory System Entry) и входящими в него объектами:

LDAP RootDSE

rootDSE можно просмотреть с помощью подходящего LDAP-браузера (вот инструкции для LDAPBrowser/Editor), указав пустой базовый DN, либо с помощью следующей команды:

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" +
# обратите внимание, что + указывает вернуть операционные атрибуты

Вывод команды будет примерно таким, как показан ниже (в OpenLDAP 2.4.8), значения в скобках — это добавленные нами объяснения, они не возвращаются сервером:

dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=example,dc=com
namingContexts: dc=example,dc=net
monitorContext: cn=Monitor
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 (Contentsync RFC 4530)
supportedControl: 2.16.840.1.113730.3.4.18 (ProxiedAuthv2 RFC 4370)
supportedControl: 2.16.840.1.113730.3.4.2 (ManageDSAIT RFC3377)
supportedControl: 1.3.6.1.4.1.4203.1.10.1 (SubEntries RFC3673)
supportedControl: 1.2.840.113556.1.4.319 (pagedResults RFC2696)
supportedControl: 1.2.826.0.1.3344810.2.3 (MatchedValues RFC3876)
supportedControl: 1.3.6.1.1.13.2 (Post Read RFC4527)
supportedControl: 1.3.6.1.1.13.1 (Pre-Read RFC4527))
supportedControl: 1.3.6.1.1.12 (Assertion RFC4528)
supportedExtension: 1.3.6.1.4.1.4203.1.11.1 (ModifyPassword RFC3088)
supportedExtension: 1.3.6.1.4.1.4203.1.11.3 (WhoAmI RFC4532)
supportedExtension: 1.3.6.1.1.8 (Cancel RFC3909)
supportedFeatures: 1.3.6.1.1.14 (Modify-Increment RFC4525)
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 (OperationalAttrs RFC3674)
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 (ObjectClassAttrs RFC4529)
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 (TrueFalse RFC4526)
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 (LanguageTag RFC3866)
supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 (LanguageRange RFC3866)
supportedLDAPVersion: 3
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
entryDN:
subschemaSubentry: cn=Subschema

Объяснение каждого supportedExtension можно найти с помощью этого замечательного сайта или этого прекрасного сайта. В этом листинге показано, что данный LDAP-сервер поддерживает два DIT — указаны как значения атрибутов namingContexts, это было сконфигурировано с помощью описанной здесь процедуры. Атрибут configContext: cn=config указывает на использование OLC (cn=config).

Существует возможность добавить LDAP-серверу расширения. При использовании OLC (cn=config) это можно сделать с помощью атрибута olcRootDSE, а при использовании slapd.conf — с помощью директивы rootDSE.

Наверх

Объекты подзаписи подсхемы (subschema subentry)

Подзапись подсхемы — интересный элемент, который можно исследовать с помощью подходящего LDAP-браузера (вот инструкции для LDAPBrowser/Editor), указав в качестве базового DN "cn=subschema", либо с помощью следующей команды:

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

Эта команда сгенерирует следующий вывод:

Примечание: в данный LDAP-сервер включены cosine.schema, core.schema, nis.schema, inetorgperson.schema.

# Subschema
dn: cn=Subschema
objectClasses: ( 2.5.6.0 NAME 'top' 
  DESC 'top of the superclass chain' 
  ABSTRACT
  MUST objectClass )
objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
  DESC 'RFC2252: extensible object' SUP top AUXILIARY )
objectClasses: ( 2.5.6.1 NAME 'alias'
  DESC 'RFC2256: an alias' SUP top STRUCTURAL
  MUST aliasedObjectName )
objectClasses: ( 2.16.840.1.113730.3.2.6 NAME 'referral' 
  DESC 'namedref: named subordinate referral' SUP top STRUCTURAL
  MUST ref )
objectClasses: ( 1.3.6.1.4.1.4203.1.4.1 NAME ( 'OpenLDAProotDSE' 'LDAProotDSE') 
  DESC 'OpenLDAP Root DSE object' SUP top STRUCTURAL
  MAY cn )
objectClasses: ( 2.5.17.0 NAME 'subentry' SUP top STRUCTURAL
  MUST ( cn $ subtreeSpecification ) )
objectClasses: ( 2.5.20.1 NAME 'subschema'
  DESC 'RFC2252: controlling subschema (sub)entry' AUXILIARY
  MAY ( dITStructureRules $ nameForms $ ditContentRules
  $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) )
objectClasses: ( 1.3.6.1.4.1.4203.666.3.2 NAME 'monitor' 
  DESC 'OpenLDAP system monitoring' STRUCTURAL MUST cn )
objectClasses: ( 2.5.6.2 NAME 'country' DESC 'RFC2256: a country'
  SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) )
objectClasses: ( 2.5.6.3 NAME 'locality' 
  DESC 'RFC2256: a locality' SUP top STRUCTURAL
  MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
objectClasses: ( 2.5.6.4 NAME 'organization' 
  DESC 'RFC2256: an 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 ) )
objectClasses: ( 2.5.6.5 NAME 'organizationalUnit'
  DESC 'RFC2256: an organizational unit' 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 ) )
objectClasses: ( 2.5.6.6 NAME 'person'
  DESC 'RFC2256: a person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
objectClasses: ( 2.5.6.7 NAME 'organizationalPerson'
  DESC 'RFC2256: an organizational person' SUP person STRUCTURAL
  MAY ( title $ x121Address $ registeredAddress $ destinationIndicator
   $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier
   $ telephoneNumber $ internationaliSDNNumber
   $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode
   $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )
objectClasses: ( 2.5.6.8 NAME 'organizationalRole'
  DESC 'RFC2256: an organizational role' 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 ) )
objectClasses: ( 2.5.6.9 NAME 'groupOfNames'
  DESC 'RFC2256: a group of names (DNs)' SUP top STRUCTURAL
  MUST ( member $ cn )
  MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
objectClasses: ( 2.5.6.10 NAME 'residentialPerson'
  DESC 'RFC2256: an residential person' SUP person STRUCTURAL
  MUST l
  MAY ( businessCategory $ x121Address $ registeredAddress
   $ destinationIndicator $ preferredDeliveryMethod $ telexNumber
   $ teletexTerminalIdentifier $ telephoneNumber
   $ internationaliSDNNumber $ facsimileTelephoneNumber
   $ preferredDeliveryMethod $ street $ postOfficeBox
   $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) )
objectClasses: ( 2.5.6.11 NAME 'applicationProcess'
  DESC 'RFC2256: an application process' SUP top STRUCTURAL
  MUST cn
  MAY ( seeAlso $ ou $ l $ description ) )
objectClasses: ( 2.5.6.12 NAME 'applicationEntity'
  DESC 'RFC2256: an application entity' SUP top STRUCTURAL
  MUST ( presentationAddress $ cn )
  MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ description ) )
objectClasses: ( 2.5.6.13 NAME 'dSA'
  DESC 'RFC2256: a directory system agent (a server)'
  SUP applicationEntity STRUCTURAL
  MAY knowledgeInformation )
objectClasses: ( 2.5.6.14 NAME 'device'
  DESC 'RFC2256: a device' SUP top STRUCTURAL
  MUST cn
  MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description) )
objectClasses: ( 2.5.6.15 NAME 'strongAuthenticationUser'
  DESC 'RFC2256: a strong authentication user' SUP top AUXILIARY
  MUST userCertificate )
objectClasses: ( 2.5.6.16 NAME 'certificationAuthority'
  DESC 'RFC2256: a certificate authority' SUP top AUXILIARY
  MUST ( authorityRevocationList $ certificateRevocationList
    $ cACertificate ) MAY crossCertificatePair )
objectClasses: ( 2.5.6.17 NAME 'groupOfUniqueNames'
  DESC 'RFC2256: a group of unique names (DN and Unique Identifier)'
  SUP top STRUCTURAL
  MUST ( uniqueMember $ cn )
  MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
objectClasses: ( 2.5.6.18 NAME 'userSecurityInformation'
  DESC 'RFC2256: a user security information' SUP top AUXILIARY
  MAY supportedAlgorithms )
objectClasses: ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
  SUP certificationAuthority AUXILIARY
  MAY deltaRevocationList )
objectClasses: ( 2.5.6.19 NAME 'cRLDistributionPoint'
  SUP top STRUCTURAL
  MUST cn
  MAY ( certificateRevocationList $ authorityRevocationList
   $ deltaRevocationList ) )
objectClasses: ( 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 ) )
objectClasses: ( 2.5.6.21 NAME 'pkiUser'
  DESC 'RFC2587: a PKI user' SUP top AUXILIARY
  MAY userCertificate )
objectClasses: ( 2.5.6.22 NAME 'pkiCA'
  DESC 'RFC2587: PKI certificate authority' SUP top AUXILIARY
  MAY ( authorityRevocationList $ certificateRevocationList
   $ cACertificate $ crossCertificatePair ) )
objectClasses: ( 2.5.6.23 NAME 'deltaCRL'
  DESC 'RFC2587: PKI user' SUP top AUXILIARY
  MAY deltaRevocationList )
objectClasses: ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject'
  DESC 'RFC2079: object that contains the URI attribute type'
  SUP top AUXILIARY MAY labeledURI )
objectClasses: ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
  DESC 'RFC1274: simple security object' SUP top AUXILIARY
  MUST userPassword )
objectClasses: ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
  DESC 'RFC2247: domain component object' SUP top AUXILIARY
  MUST dc )
objectClasses: ( 1.3.6.1.1.3.1 NAME 'uidObject'
  DESC 'RFC2377: uid object' SUP top AUXILIARY
  MUST uid )
objectClasses: ( 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 ) )
objectClasses: ( 0.9.2342.19200300.100.4.5 NAME 'account'
  SUP top STRUCTURAL
  MUST userid
  MAY ( description $ seeAlso $ localityName $ organizationName
  $ organizationalUnitName $ host ) )
objectClasses: ( 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 ) )
objectClasses: ( 0.9.2342.19200300.100.4.7 NAME 'room'
  SUP top STRUCTURAL
  MUST commonName
  MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
objectClasses: ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
  SUP top STRUCTURAL
  MUST commonName
  MAY ( description $ seeAlso $ telephonenumber $ localityName
   $ organizationName $ organizationalUnitName ) )
objectClasses: ( 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 ) )
objectClasses: ( 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 ) )
objectClasses: ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain'
  SUP domain STRUCTURAL
  MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord
   $ CNAMERecord) )
objectClasses: ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
  DESC 'RFC1274: an object related to an domain'
  SUP top AUXILIARY
  MUST associatedDomain )
objectClasses: ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
  SUP country STRUCTURAL
  MUST friendlyCountryName )
objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'
  SUP ( organization $ organizationalUnit ) STRUCTURAL
  MAY buildingName )
objectClasses: ( 0.9.2342.19200300.100.4.21 NAME 'pilotDSA'
  SUP dsa STRUCTURAL
  MAY dSAQuality )
objectClasses: ( 0.9.2342.19200300.100.4.22 NAME 'qualityLabelledData'
  SUP top AUXILIARY
  MUST dsaQuality MAY ( subtreeMinimumQuality $ subtreeMaximumQuality ) )
objectClasses: ( 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 ) )
objectClasses: ( 1.3.6.1.1.1.2.0 NAME 'posixAccount'
  DESC 'Abstraction of an account with POSIX attributes'
  SUP top AUXILIARY
  MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
  MAY ( userPassword $ loginShell $ gecos $ description ) )
objectClasses: ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount'
  DESC 'Additional attributes for shadow passwords'
  SUP top AUXILIARY MUST uid MAY ( userPassword $ shadowLastChange
  $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive
  $ shadowExpire $ shadowFlag $ description ) )
objectClasses: ( 1.3.6.1.1.1.2.2 NAME 'posixGroup'
  DESC 'Abstraction of a group of accounts'
  SUP top STRUCTURAL
  MUST ( cn $ gidNumber )
  MAY ( userPassword $ memberUid $ description ) )
objectClasses: ( 1.3.6.1.1.1.2.3 NAME 'ipService'
  DESC 'Abstraction an Internet Protocol service'
  SUP top STRUCTURAL
  MUST ( cn $ ipServicePort $ ipServiceProtocol )
  MAY description )
objectClasses: ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol'
  DESC 'Abstraction of an IP protocol' SUP top STRUCTURAL
  MUST ( cn $ ipProtocolNumber $ description )
  MAY description )
objectClasses: ( 1.3.6.1.1.1.2.5 NAME 'oncRpc'
  DESC 'Abstraction of an ONC/RPC binding'
  SUP top STRUCTURAL
  MUST ( cn $ oncRpcNumber $ description )
  MAY description )
objectClasses: ( 1.3.6.1.1.1.2.6 NAME 'ipHost'
  DESC 'Abstraction of a host, an IP device'
  SUP top AUXILIARY
  MUST ( cn $ ipHostNumber )
  MAY ( l $ description $ manager ) )
objectClasses: ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork'
  DESC 'Abstraction of an IP network' 
  SUP top STRUCTURAL
  MUST ( cn $ ipNetworkNumber )
  MAY ( ipNetmaskNumber $ l $ description $ manager ) )
objectClasses: ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup'
  DESC 'Abstraction of a netgroup'
  SUP top STRUCTURAL
  MUST cn
  MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
objectClasses: ( 1.3.6.1.1.1.2.9 NAME 'nisMap'
  DESC 'A generic abstraction of a NIS map'
  SUP top STRUCTURAL
  MUST nisMapName
  MAY description )
objectClasses: ( 1.3.6.1.1.1.2.10 NAME 'nisObject'
  DESC 'An entry in a NIS map' SUP top STRUCTURAL
  MUST ( cn $ nisMapEntry $ nisMapName )
  MAY description )
objectClasses: ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device'
  DESC 'A device with a MAC address' SUP top AUXILIARY
  MAY macAddress )
objectClasses: ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice'
  DESC 'A device with boot parameters' SUP top AUXILIARY
  MAY ( bootFile $ bootParameter ) )

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

Наверх

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

Перейти



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

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

Copyright © 1994-2015 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 1 апреля 2015 г.
Переведено участниками проекта Pro-LDAP.ru в 2011-2015 г.