| |
![]() |
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.1 Политика безопасности
5.2.2 Добавление групп
5.2.3 ACL — директивы access файла slapd.conf
5.2.4 Тестирование ACL
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 Отсылки и репликация
В этом разделе мы создадим несколько атрибутов, объектный класс, а также набор схемы, чтобы упаковать всё это на будущее.
Видя ещё более успешное внедрение LDAP, руководители нашей корпорации решили добавить в текущую реализацию нашего каталога следующие возможности:
Атрибут dohicky. Этот атрибут будет содержать логические значения. Его смогут просматривать и обновлять только владелец записи и любой член группы hrpeople.
Атрибут ageAtBirth (обратите внимание на особенно глупую псевдовенгерскую нотацию — Вы видите такое в последний раз). Этот атрибут будет содержать числовые значения. Его смогут просматривать и обновлять только владелец записи и любой член группы hrpeople.
Атрибут gobbledegook. Этот атрибут будет содержать строковые значения и будет публично доступен для просмотра всем пользователям, прошедшим аутентификацию. Его смогут обновлять только владелец записи и любой член группы hrpeople. Од должен быть доступен для поиска с помощью поисковых фильтров <= и >=.
В рамках нашего перехода на технологию единого входа (SSO), мы добавим каждому пользователю стандартный объектный класс posixAccount. Данная запись будет доступна для просмотра только группе itpeople.
Мы очень старались найти среди существующих атрибутов объектного класса inetorgperson такие, которые можно было бы использовать под наши нужды (попросту, использовать существующие атрибуты с необходимым синтаксисом (SYNTAX), несмотря на то, что их оригинальное "предназначение" разрабатывалось для иных целей), но, увы, ничего не вышло. Итак, нам остаётся только создать свои собственные объекты. Вот что мы хотим, или точнее, что мы должны сделать:
Атрибут dohicky. Создадим свой собственный, используя OID существующего синтаксиса boolean.
Атрибут ageAtBirth. Создадим свой собственный, используя OID существующего синтаксиса integer.
Атрибут gobbledegook. Создадим свой собственный, используя OID существующего синтаксиса PrintableString. А для того, чтобы получить возможность пользоваться поисковыми фильтрами <= и >=, нужно использовать правило соответствия ORDERING (caseIgnoreOrderingMatch).
Для этих трёх атрибутов мы создадим новый объектный класс и назовём его ourObject (довольно креативное имя). Поскольку в каждой записи у нас уже есть структурный (STRUCTURAL) объект (inetorgperson), мы будем использовать вспомогательный (AUXILIARY) объектный класс.
Если бы нам требовались структурные объекты, нам пришлось бы делать их всех дочерними по отношению к нашим текущим записям inetorgperson, как мы уже делали на предыдущем шаге с частными адресными книгами. Альтернативный путь: мы могли бы сделать ourObject структурным и использовать в его определении sup inetOrgPerson, добавляя его, таким образом, в конец иерархии объектных классов Person ->organizationalPerson ->inetOrgPerson (смотрите определение объектного класса).
При создании и объектного класса и атрибутов требуется, чтобы они были глобально уникальными. В данном примере используются глобально уникальные OID, которые можно безопасно использовать В ЦЕЛЯХ ТЕСТИРОВАНИЯ ЭТОГО ПРИМЕРА. НЕ ПОДДАВАЙТЕСЬ ИСКУШЕНИЮ ПОВТОРНО ИСПОЛЬЗОВАТЬ ЭТИ ИЛИ ЛЮБЫЕ ДРУГИЕ OID. Получение собственного номера для своего предприятия, позволяющего определять свои собственные атрибуты и объектные классы — простая и бесплатная процедура, предоставляемая IANA. Использование существующих OID — очень скверная штука (VERY BAD THING™).
Поскольку наше любимое и уважаемое корпоративное руководство вряд ли остановится на этом, мы решили упаковать эти фенечки (атрибуты и объектный класс) в набор схемы, который мы назовём ourco.schema (опять же, весьма оригинально).
Слава Богу, объектный класс posixAccount — это вспомогательный (AUXILIARY) класс. Поскольку некоторые атрибуты данного объектного класса используются и в других объектных классах, мы пересмотрим ту драконовскую директиву, которая разрешает доступ к атрибутам posixAccount только для itpeople. Теперь мы ограничим доступ только к уникальным атрибутам данного объектного класса, в частности — homedirectory, gidnunber, uidnumber, loginshell и gecos.
Мы создали следующие определения атрибутов:
attributetype ( 1.3.6.1.4.1.6863.2.3.107 NAME 'dohicky' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
OID данного атрибута построен согласно предполагаемому нами соглашению о нумерации. Мы используем OID стандартного синтаксиса типа данных boolean. Правило соответствия — только EQUALITY. Дополнительную информацию по определению атрибутов можно найти здесь.
attributetype ( 1.3.6.1.4.1.6863.2.3.108 NAME 'ageAtBirth' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
OID данного атрибута построен согласно предполагаемому нами соглашению о нумерации. Мы используем OID стандартного синтаксиса типа данных integer. Правила соответствия — EQUALITY и ORDERING. Дополнительную информацию по определению атрибутов можно найти здесь.
Порой можно встретить варианты gobbledigook или даже gobbledygook — не обращайте внимания, у нас самый точный вариант написания!
attributetype ( 1.3.6.1.4.1.6863.2.3.109 NAME 'gobbledegook' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{200} )
OID данного атрибута построен согласно предполагаемому нами соглашению о нумерации. Для данного атрибута мы используем OID стандартного синтаксиса типа данных PrintableString и определяем максимальную длину строки в 200 символов (в фигурных скобках). Правила соответствия — EQUALITY, SUBSTR и ORDERING. . Дополнительную информацию по определению атрибутов можно найти здесь.
objectclass ( 1.3.6.1.4.1.6863.2.4.57 NAME 'ourObject' DESC 'A very useful object' SUP top AUXILIARY MUST ( dohicky $ gobbledegook ) MAY ageAtBirth )
OID данного объектного класса построен согласно предполагаемому нами соглашению о нумерации.
SUP top ограничивает иерархию объектных классов с помощью удобного объектного класса top.
AUXILIARY позволяет нам использовать данный объектный класс совместно с любым структурным объектным классом.
MUST ( dohicky $ gobbledegook ) определяет, что атрибуты dohicky и gobbledegook должны присутствовать в той записи, куда добавляется данный объектный класс. А MAY ageAtBirth, напротив, говорит о том, что данный атрибут является необязательным.
Дополнительную информацию по определению объектных классов можно найти здесь.
Наконец, мы добавим все вышеперечисленные элементы в файл и сохраним его как ourco.schema в той же директории, где находятся поставляемые с дистрибутивом наборы схемы. Конечно, можно сохранить его где угодно, но когда всё лежит в одном месте — сложнее запутаться.
Немного о белках: Пункт DESC большинства объектных классов и типов атрибутов, как правило, столь же значим и полезен, как и в примере нашего объектного класса. В этой жизни множество раздражающих вещей, и одна из них, — то, что мы называем "комплексом белки", — неестественное желание скрыть суть или предназначение того или иного предмета. Однажды поэта лорда Байрона спросили о значении строки одного из его стихотворений. Он ответил: "Когда я писал это, значение было известно мне и Богу, а теперь — одному только Богу". Всё рано или поздно забывается. Почему бы не добавить несколько слов осмысленного описательного текста? Особенно если разработчики предусматривают какие-нибудь серьёзные ограничения или особое использование своего объекта.
# ФАЙЛ НАБОРА СХЕМЫ EXAMPLE.COM # атрибут принимает значение: # true = надевает свежие носки по понедельникам # false = не надевает свежие носки по понедельникам attributetype ( 1.3.6.1.4.1.6863.2.3.107 NAME 'dohicky' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) # если присутствует, должен быть равен 0 attributetype ( 1.3.6.1.4.1.6863.2.3.108 NAME 'ageAtBirth' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) # строка, используемая для описания роста человека в футах/дюймах или метрах # може быть представлена в виде xfyi, например 5f7i (5 футов 7 дюймов) или x.ym, например 1.95m (1.95 метра) # значения f, i, m не чувствительны к регистру attributetype ( 1.3.6.1.4.1.6863.2.3.109 NAME 'gobbledegook' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{200} ) # объектный класс, используемый в адресной книге для определения необходимой информации # согласно Федеральному закону 5.7.3 — эти данные определены как конфиденциальные — требуется ограниченный доступ objectclass ( 1.3.6.1.4.1.6863.2.4.57 NAME 'ourObject' DESC 'A very useful object' SUP top AUXILIARY MUST ( dohicky $ gobbledegook ) MAY ageAtBirth )
Мы должны внести изменения в файл slapd.conf, во-первых, для того, чтобы подправить права доступа, а главное — для того, чтобы сообщить OpenLDAP о нашем новом объектном классе с помощью директивы include /usr/local/etc/openldap/schema/ourco.schema, чтобы он не задохнулся при виде атрибута dohicky. Вот наш изменённый slapd.conf:
# ###### ПРИМЕР 4 — КАТАЛОГ с доморощенными объектным классом и атрибутами ############ # # Примечание: inetorgperson использует атрибуты и # объектные классы из всех трёх наборов схемы # объектный класс device определён в core.schema # объектный класс posixAccount — в nis.schema # добавляется ourco.schema # # NB: В RH Linux наборы схемы располагаются в /etc/openldap # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/ourco.schema # НЕТ ОТСЫЛОК # НЕ заботимся о файле ARGS, пока не обретём уверенность в своих силах # stop-скрипту slapd следующая строка необходима для работы: pidfile /var/run/slapd.pid # Включаем большое количество вывода в журнал — нам это может понадобиться loglevel -1 # НЕТ динамических модулей backend # НЕТ соединений TLS ####################################################################### # Определение базы данных bdb # # Замените ниже example и com на подходящее имя домена # # Если у Вас нет домена, то, поскольку example.com зарезервирован для # экспериментов, можете оставить его, либо поменять на my.inc ####################################################################### database bdb suffix "dc=example, dc=com" # ACL1 # только владелец и члены itgroup могут просматривать и обновлять access to attrs=userpassword by self write by anonymous auth by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write by * none # ACL1A # только владелец и члены itgroup могут просматривать и обновлять access to attrs=homedirectory,uidnumber,gidnumber,loginshell,gecos by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write by * none # ACL2 # разрешаем читать addressbook владельцу и itpeople; остальные не могут её просматривать access to dn.regex="^ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$" attrs=entry by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" read by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write by users none # ACL3 # разрешаем itgroup создавать addressbook, но не просматривать записи access to dn.regex="cn=[^,]+,ou=people,dc=example,dc=com$" attrs=children by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write by users none break # ACL4 # разрешаем создавать записи в своей собственной addressbook; # остальные не могут получить к ней доступ, требуются права на запись # в атрибут ENTRY (ACL5) и дочерние (CHILDREN) записи данной записи (ACL4) access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$" attrs=children by dn.regex,expand="cn=$1,ou=people,dc=example,dc=com" write by users none # ACL5 # разрешаем создание записей в своей addressbook; # остальные не могут получить к ней доступ, требуются права на запись # в атрибут ENTRY (ACL5) и дочерние (CHILDREN) записи данной записи (ACL4) access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$" attrs=entry by dn.regex,expand="cn=$1,ou=people,dc=example,dc=com" write by users none # ACL6 # разрешаем создание записей в своей addressbook; # остальные не могут получить к ней доступ access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$" filter=(objectclass=inetorgperson) by dn.regex,expand="cn=$1,ou=people,dc=example,dc=com" write by users none # В LDAP 2.2+ ACL5 и ACL6 заменяются на: #access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$" # attrs=entry,@inetorgperson # by dn.regex,expand="cn=$1,ou=people,dc=example,dc=com" write # by users none # ACL7 # разрешаем sales создание записей в customers # пользователи, прошедшие аутентификацию получают доступ только на чтение access to dn.one="ou=customers,dc=zytrax,dc=com" attr=children by group.exact="cn=salespeople,ou=groups,dc=example,dc=com" write by users read # ACL8 access to attr=carlicense,homepostaladdress,homephone,dohicky,ageatbirth by self write by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write by * none # ACL8A — контроль доступа к equipment access to dn.one="ou=equipment,dc=example,dc=com" by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write by users read by * none # ACL9 access to * by self write by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write by users read by * none # root или администратор rootdn "cn=jimbob, dc=example, dc=com" rootpw dirtysecret # Директория базы данных ДОЛЖНА существовать до того, как Вы запустите slapd # Не забудьте поменять путь на подходящий Вам directory /var/db/openldap/example-com # Устанавливаемые для каталога индексы # Только полное соответствие для unique id index uid eq # Стандартный поиск для commonname, givenname и email index cn,gn,mail eq,sub # Несколько вариантов для поиска surname index sn eq,sub # В индексах выше sub включает в себя subintial,subany,subfinal # Оптимизируем поиск по подразделениям index ou eq # Если при поиске будет встречаться objectClass, раскомментируйте следующую строку # index objectClass eq # Продемонстрировано использование параметра индексирования default index default eq,sub # Настройка индексирования пропущена, по умолчанию используется eq,sub index telephonenumber # Другие параметры базы данных # Дополнительная информация в разделе справочника по slapd.conf cachesize 10000 checkpoint 128 15
Чтобы получить данный пример в виде отдельного текстового файла, используйте эту ссылку и функцию сохранить как Вашего браузера.
Примечания:
Мы добавили директивы include для подключения наборов схемы nis.schema (для posixAccount) и ourco.schema (для ourObject и различных атрибутов).
Мы добавили директиву access (ACL1A), чтобы ограничения доступа касались только атрибутов homedirectory, uidnumber и gidnumber (к ним доступ получают только члены itgroup согласно требованиям нашей политики безопасности). В OpenLDAP версий 2.2+ мы можем использовать синтаксис attr=@posixaccount (все атрибуты объектного класса posixAccount), но тогда у нас будет незначительный побочный эффект ограничения доступа к cd! Не совсем то, что мы хотим.
Мы добавили dohickey и ageatbirth в директиву access (ACL8), предоставляя доступ к этим атрибутам только членам группы hrgroup и владельцу записи.
Теперь нам нужно остановить и снова запустить OpenLDAP, чтобы он принял новый файл slapd.conf. Это делается с помощью следующих команд:
# Остановка и запуск OpenLDAP (slapd) # Linux/Redhat /etc/rc.d/init.d/ldap restart # BSD [bsd] /usr/local/etc/openldap/slapd.sh stop # затем [bsd] /usr/local/etc/rc.d/slapd.sh start # убеждаемся, что slapd запущен ps ax | grep slapd
С помощью приведённого ниже LDIF в наши записи вносятся изменения. Добавляется объектный класс posixAccount и его обязательные атрибуты, а также объектный класс ourObject со своими обязательными атрибутами.
Ни один из используемых нами LDAP-браузеров не позволяет добавлять новые вспомогательные (AUXILIARY) объектные классы. Видимо, LDIF — единственный способ сделать это.
version: 1 dn: cn=john smith,ou=people,dc=example,dc=com changetype: modify objectclass: inetorgperson objectclass: posixaccount uidnumber: 200 gidnumber: 203 homedirectory: /var/mail/example.com/jsmith objectclass: ourObject dohicky: false gobbledegook: john ageatbirth: 0 dn: cn=sheri smith,ou=people,dc=example,dc=com changetype: modify objectclass: inetorgperson objectclass: posixaccount uidnumber: 201 gidnumber: 203 homedirectory: /var/mail/example.com/ssmith objectclass: ourObject dohicky: true gobbledegook: sheri dn: cn=robert smith,ou=people,dc=example,dc=com changetype: modify objectclass: inetorgperson objectclass: posixaccount uidnumber: 202 gidnumber: 203 homedirectory: /var/mail/example.com/rsmith objectclass: ourObject dohicky: false gobbledegook: robert ageatbirth: 17
Примечания:
Предположим, что мы сохранили приведённый выше LDIF как modify.ldif в директории /tmp. Тогда мы будем загружать LDIF-файл с помощью примерно такого вызова ldapmodify (приведённая ниже команда разбита на две строки только из соображений форматирования HTML и должна записываться в одну строку):
ldapmodify -H ldap://ldaphost.example.com -x -D "cn=jimbob,dc=example,dc=com" -f /tmp/modify.ldif -w dirtysecret
Замените ldaphost.example.com на имя того хоста, на котором располагается Ваш каталог LDAP. Если мы вызываем команду на том же хосте, на котором работает LDAP-сервер, параметр -H может быть опущен. Параметр -x указывает, что мы не будем использовать SASL-аутентификацию, он требуется только начиная с OpenLDAP версий 2.x. В параметре -D указан DN, от имени которого мы производим подключение, в данном случае rootdn — администратору приходится выполнять всю работу. Указывать пароль вслед за параметром -w, как мы это сделали в примере, мягко скажем, небезопасно, Вы можете использовать -W, тогда пароль будет запрошен после вызова команды.
Теперь нужно проверить внесённые нами изменения. Для проверки ACL используйте Ваш LDAP-браузер и следующие тесты:
Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=Robert Smith, ou=people, dc=example, dc=com с паролем (userpassword) rJsmitH (регистр символов имеет значение). Поскольку у данной записи есть привилегии hrpeople, её владелец сможет просматривать и изменять все записи, в том числе атрибуты carlicense, homepostaladdress и homephone, но не атрибут userpassword (за исключением своей собственной записи), а также сможет читать записи customers и equipment, но не писать в них. Robert Smith также может просматривать и добавлять записи в свою собственную подзапись адресной книги (addressbook), но может только догадываться, есть ли у кого-нибудь еще адресная книга (то есть не может увидеть запись addressbook у кого-либо другого). Он не может видеть атрибуты homedirectory, guidnumber, gidnumber, loginshell и gecos объектного класса posixAccount в своей собственной и в любой другой записи.
Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=Sheri Smith, ou=people, dc=example, dc=com с паролем (userpassword) sSmitH (регистр символов имеет значение). Поскольку у данной записи есть привилегии itpeople, её владелица сможет просматривать и изменять атрибуты userpassword, homedirectory, guidnumber, gidnumber, loginshell и gecos всех записей, не не сможет просматривать атрибуты carlicense, homepostaladdress и homephone какой-либо записи, за исключением своей собственной. Она сможет читать записи в ветке customers, но не сможет писать туда. Она сможет читать и записывать записи в ветку equipment. Sheri Smith также может просматривать и добавлять записи в свою собственную подзапись адресной книги (addressbook), а также видеть подзапись addressbook (но не дочерние ей подзаписи) у любого человека. Она может также удалить подзапись addressbook у любой записи (и если Вы хотите это попробовать, не переживайте, Вы также можете добавить её назад!)
Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=John Smith, ou=people, dc=example, dc=com с паролем (userpassword) jSmitH (регистр символов имеет значение). Поскольку у данной записи нет привилегий, её владелец не сможет просматривать атрибуты carlicense, homepostaladdress, homephone и userpassword какой-либо записи, за исключением своей собственной (которую, также, сможет и модифицировать). Поскольку данная запись является членом группы salespeople, её владелец сможет читать и записывать записи в ветке customers, а записи в ветке equipment сможет только читать. John Smith также может просматривать и добавлять записи в свою собственную подзапись адресной книги (addressbook), но может только догадываться, есть ли у кого-нибудь еще адресная книга (то есть не может увидеть запись addressbook у кого-либо другого). Он не может видеть атрибуты homedirectory, guidnumber, gidnumber, loginshell и gecos объектного класса posixAccount в своей собственной и в любой другой записи.
Настройте Ваш LDAP-браузер на анонимное подсоединение и убедитесь, что доступ запрещён.
Пройдите аутентификацию от имени настроенного нами rootdn или администратора (определён в slapd.conf как cn=jimbob,dc=example,dc=com, пароль dirtysecret) и убедитесь, что в этом случае игнорируются все наши привилегии и можно просматривать и изменять всё что угодно.
На данном этапе может быть полезно экспортировать текущее состояние каталога в LDIF с помощью функции экспорта Вашего LDAP-браузера, либо slapcat.
Примечание: Во всех приведённых выше тестах Вы должны быть в состоянии с помощью Вашего LDAP-браузера просматривать ветки customers, equipment и groups, а также записи в них. Если этого не происходит, то, вероятно, Вы установили значение Base DN (или Root DN) Вашего LDAP-браузера в ou=people,dc=example,dc=com. Установите его в dc=example,dc=com, и тогда Вы сможете просматривать все эти записи.
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 21 октября 2015 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2013 г.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |