Глава 3. Схема данных, объектные классы и атрибуты 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 сгруппированы наборы объектных классов:

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

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

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

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

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

   • Записи могут быть трёх типов: записи-объекты (самый распространённый тип записи), состоящие из из пользовательских данных, содержащихся в атрибутах, входящих в состав объектных классов; записи-псевдонимы, построенные на объектном классе alias, имеющем в своём составе единственный атрибут aliasedObjectName; подзаписи, используемые для хранения административной или операционной информации, относящейся (каким-либо образом) к родительской записи данной подзаписи.

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

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

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

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

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

При использовании конфигурационного файла slapd.conf серверу сообщают о наборах схемы с помощью директивы include.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

objectclass ( 2.5.6.2 NAME 'country' DESC 'RFC2256: a 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 'a country'. Ну ладно, мы выбрали неудачный пример, где в операторе DESC не приведено глубокомысленное описание — зато определение объектного класса получилось коротким. DESC — это необязательное значение, предоставляющее текстовое описание порядка использования или содержимого объектного класса. Оно предназначено для чтения людьми и другого применения не имеет. Вот на что стало бы похоже country, если бы в него включили осмысленный оператор DESC:

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL
  DESC 'A geographic entity described by a 2 letter ISO 3166 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.1.2 RFC 4512 и выглядит так:

AttributeTypeDescription = "(" whsp
   numericoid whsp     ; идентификатор типа атрибута
 [ "NAME" qdescrs ]             ; имя, используемое в типе атрибута
 [ "DESC" qdstring ]            ; описание
 [ "OBSOLETE" whsp ]
 [ "SUP" oid ]                  ; происходит от этого
                                ; типа атрибута
 [ "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
 extensions
 whsp ")"

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

Атрибуты определяются с помощью нотаций 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, то есть он может появляться более одного раза в записи c объектным классом, в котором присутствует этот атрибут. Если какой-то атрибут может принимать только одно значение (может появляться только раз в записи c объектным классом, в котором присутствует этот атрибут), это должно быть явно указано, как в определении атрибута 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 или directoryOperation, тогда этот атрибут будет операционным (возвращается, если при поиске в списке атрибутов есть значение +).

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 )

COLLECTIVE. Коллективные атрибуты определены в RFC 3671. Указание ключевого слова COLLECTIVE является верным только совместно с USAGE 'userApplication' (значение по умолчанию), а также при условии, когда наличие его в определении атрибута позволяет всем экземплярам вышестоящих (SUP) по отношению к этому атрибуту атрибутов иметь то же самое значение, например, как в атрибуте telephoneNumber. По соглашению, имя, выделяемое для коллективного атрибута, будет соответствовать имени вышестоящего (SUP) атрибута с префиксом c-, то есть COLLECTIVE-атрибут с вышестоящим атрибутом telephoneNumber — это c-telephoneNumber. Пример определения коллективного атрибута:

( 2.5.4.20.1 NAME 'c-TelephoneNumber'
     SUP telephoneNumber COLLECTIVE )

Коллективные атрибуты могут появляться в подзаписях с объектным классом collectiveAttributeSubentry. Путём модификации коллективного атрибута (атрибутов) (через соответствующие подзаписи) можно изменить все экземпляры вышестоящих (SUP) атрибутов.

NO-USER-MODIFICATION. Данное ключевое слово, при его наличии, указывает, что этот атрибут не может быть модифицирован пользователем независимо от любых назначенных прав в определениях системы безопасности и ACL. Как правило, оно присутствует только тогда, когда в качестве USAGE указано dsaOperation или directoryOperation. При отсутствии этого ключевого слова атрибут может модифицироваться пользователем (при соблюдении политик системы безопасности и ACL).

X-. В любом объекте LDAP могут определяться дополнительные свойства помимо тех, которые определены в соответствующих стандартах (хотя очевидно, что они должны опознаваться одной или несколькими реализациями LDAP-сервера, чтобы от них был какой-то прок). Все подобные свойства должны начинаться с X- (в качестве примера смотрите ниже описание ключевого слова X-ORDERED, которое распознаётся OpenLDAP), и должны иметь единственный заключённый в одинарные кавычки параметр, например, X-MY-PROPERTY 'TRUE'.

X-ORDERED:

Большинство читателей могут, к счастью, пропустить данные замечания. Они приводятся здесь только для тех, кто копается в недрах 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 (которые обозначаются отсутствием SINGLE-VALUE в определении атрибута) и указывает на то, что каждый атрибут будет иметь порядковый элемент в форме {x}, добавляемый в начало значения данного атрибута (и становящийся частью этого значения), где x — число, означающее порядковый номер и начинающееся с 0. Это позволяет при обращении к атрибутам с несколькими значениями явно указывать то значение, к которому мы хотим обратиться (для операций модификации или удаления), а при добавлении новых значений атрибута, для которых важен или существенен порядок их указания (например, при составлении ACL/ACP с помощью атрибута olcAccess), явно указать место его нахождения в упорядоченном множестве.

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

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

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

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

---

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

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