OID

   1.3.6.1.4.1.1466.115.121.1.38

Кроме типа атрибута можно указывать дополнительные его параметры:

n  DESC – строка (обычный текст), которая описывает данный атрибут.

n  SUP – строка (имя) или OID родительского атрибута (происходит наследование синтаксиса родительского атрибута).

n  EQUALITY – строка (наименование) или OID метода поиска, например, caseIgnoreMatch для поиска данного атрибута без учёта регистра.

n  SINGLE-VALUE – просто флаг (после него должен обязательно стоять пробел!), который указывает, что данный атрибут может принимать только единственное значение (по умолчанию ему можно присваивать несколько значений).

n  NO-USER-MODIFICATION – флаг, запрещающий модификацию данного атрибута пользователем (по умолчанию модификация разрешена).

При составлении схемы учтите, что после каждой лексемы (включая скобки и флаги) должен идти один пробел. Приведу пример составления атрибута картинки как пути к jpg-файлу:

attributetype ( 1.1.2.1.2 NAME 'pic' DESC 'my jpeg picture' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

И, например, картинки на сайте, представленной в виде URL:

attributetype ( 1.1.2.1.3 NAME 'URLpic' DESC 'URL to picture' SUP pic )

Создание нового класса несколько проще, приведу пример класса cronEntry из cron.schema:

objectclass (1.3.6.1.4.1.7006.1.3.2.1

    NAME 'cronEntry'

    SUP top

    STRUCTURAL

    MUST ( cn $ cronCommand $ uid )

    MAY ( cronHost $

           cronMinute $

           cronHour $

           cronDay $

           cronMonth $

           cronDayOfWeek $

           owner $

           description ) )

Вначале идёт OID, имя (не забудьте кавычки), родительский класс (наследуются атрибуты), тип класса (для знакомых с объектно-ориентированной моделью объясняю: ABSTRACT – абстрактный (нельзя делать объекты данного класса, можно только наследовать) и STRUCTURAL – обычный (по умолчанию)). Далее идут поля атрибутов для класса: MUST – обязательные атрибуты, MAY – необязательные. Список атрибутов заключается в скобки и разделяется по странной прихоти не запятыми, а знаками доллара (очевидно, это намёк разработчиков). Думаю, тут можно ещё раз напомнить о необходимости пробелов после каждой лексемы (и долларов тоже). Вот видите, создание объектов – не такая уж и тяжёлая вещь. Примеров приводить не буду, т.к. класс cronEntry является идеальным объектом для рассмотрения. Честно говоря, я всё-таки рекомендовал бы всем, кто собирается создавать новую схему, посмотреть существующие, т.к. во-первых, необходимо убедиться в уникальности OID, а во-вторых, меньше будет ошибок в своей схеме.

В качестве заключения

Я думаю, что если у вас в распоряжении находится крупная сеть, то применение LDAP является идеальным решением централизованного управления аутентификацией на всех уровнях. Использование реплик делает LDAP надёжным, а хорошие методы шифрования обеспечивают приличную степень безопасности. Кроме этого, LDAP является довольно быстрым механизмом поиска и, что очень важно, хранит всё в древовидной базе данных. Для небольших сетей, я думаю, лучше использовать текстовые файлы: просто и сердито, а главное быстрее чем LDAP. Но в крупных сетях это приведёт к тихому ужасу, связанному с конфликтами разных пользователей, машин, серверов. Я сам был свидетелем сетки из ~1000 машин, соединённых банальной сеткой мелкомягких (без доменов!), где NovellNetware использовалась лишь как файл-сервер. LDAP и SAMBA в этом случае снимают большинство этих проблем. Итак, на этот раз всё. В следующий раз я расскажу о популярных LDAP-клиентах и серверах, о создании собственных клиентов.