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 Отсылки и репликация
А теперь с помощью директив access в slapd.conf добавим к нашему каталогу несколько правил безопасности.
Мы собираемся строить политику контроля доступа (Access Control Policy, ACP, известную также как ACL) на основании корпоративной политики безопасности (круто!), которая гласит:
Владелец записи каталога имеет право просматривать ВСЕ атрибуты своей записи, включая пароли.
Сотрудники отдела Human Resources должны иметь право обновлять ЛЮБУЮ запись, но не должны иметь прав на чтение или запись паролей пользователей.
В записях каталога атрибуты carlicence, homepostaddress и homephone не должны быть доступны для чтения кому бы то ни было, за исключением сотрудников отдела Human Resources, а также владельца записи каталога.
Все пользователи должны проходить аутентификацию (анонимный доступ не разрешается).
Сотрудники отдела IT должны иметь право обновлять или изменять пароль записи во всех записях каталога.
Что бы Вы ни думали о такой политике, мы собираемся разрабатывать контроль доступа, воплощающий её в жизнь. Первое, что мы сделаем — это создадим две группы для hrpeople и itpeople, что позволит нам назначать групповые привилегии. Мы разместим эти группы в ветке groups, которая будет находиться в первом уровне иерархии сразу за корневой записью DIT. Приведённая ниже диаграмма показывает нашу новую структуру.
Следующий LDIF демонстрирует, как мы добавили группы с помощью LDIF.
version: 1 # Создаём ветку groups ПЕРВОГО уровня иерархии dn: ou=groups,dc=example,dc=com objectclass:organizationalunit ou: groups description: generic groups branch # Создаём запись itpeople в groups dn: cn=itpeople,ou=groups,dc=example,dc=com objectclass: groupofnames cn: itpeople description: IT security group member: cn=William Smith,ou=people,dc=example,dc=com # Создаём запись hrpeople в groups dn: cn=hrpeople,ou=groups,dc=example,dc=com objectclass: groupofnames cn: hrpeople description: Human Resources group member: cn=Robert Smith,ou=people,dc=example,dc=com
Чтобы получить данный пример в виде отдельного текстового файла, используйте эту ссылку и функцию сохранить как Вашего браузера.
Примечания:
Для определения группы мы использовали объектный класс groupOfNames.
member: dn определяет члена (членов) группы по их DN.
Наблюдательные (или до сих пор не заснувшие) читатели отметили, что в настоящий момент в нашем DIT отсутствует запись для member: cn=William Smith,ou=people,dc=example,dc=com. Это вполне допустимо. При добавлении атрибута member никаких проверок не производится. В данном случае единственным следствием этого будет лишь то, что в текущий момент в нашем DIT нет ни одной записи, которая была бы членом группы itpeople. Возможно, мы забыли добавить William Smith, возможно, мы добавим эту запись позже. А может быть мы просто ошиблись!
Предположим, что мы сохранили приведённый выше LDIF как addgroups.ldif в директории /tmp. Тогда мы будем загружать LDIF-файл с помощью примерно такого вызова ldapadd (приведённая ниже команда разбита на две строки только из соображений форматирования HTML и должна записываться в одну строку):
ldapadd -H ldap://ldaphost.example.com -x -D "cn=jimbob,dc=example,dc=com" -f /tmp/addgroups.ldif -w dirtysecret
Замените ldaphost.example.com на имя того хоста, на котором располагается Ваш каталог LDAP.
Теперь нам нужно перевести нашу политику безопасности в списки контроля доступа (Access Control List, ACL), используя директивы access to файла slapd.conf OpenLDAP.
Здесь описывается, как мы реализовали данную политику с подробными примечаниями, а также показано, как это выглядит в формате OLC (cn=config).
В листинге ниже приводится наш оригинальный пример slapd.conf с изменениями, включающими нашу политику контроля доступа.
# ###### ПРИМЕР 2 — КАТАЛОГ С ACL ############ # # Примечание: inetorgperson использует атрибуты и # объектные классы из всех трёх наборов схемы # # 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 # НЕТ ОТСЫЛОК # НЕ заботимся о файле 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 access to attrs=userpassword by self write by anonymous auth by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write by * none # ACL2 access to attrs=carlicense,homepostaladdress,homephone by self write by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write by * none # ACL3 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
Примечание: Атрибуты carlicense и hometelephone присутствуют не в каждой записи созданного в настоящий момент DIT, а атрибута homePostalAddress вообще нет ни в одной записи. В связи с этим можно выделить два момента. Во-первых, данные ACL являются выражением нашей политики безопасности и не связаны с текущим содержимым DIT. Во-вторых, поскольку все эти атрибуты являются частью иерархии объектных классов inetOrgPerson (->organizationalPerson->Person), они могут быть в будущем в любой момент добавлены в любую запись, таким образом эти ACL необходимы для определения нашей полной политики контроля доступа с самого начала создания нашего DIT.
Чтобы получить данный пример в виде отдельного текстового файла, используйте эту ссылку и функцию сохранить как Вашего браузера.
Теперь нам нужно остановить и снова запустить OpenLDAP, чтобы он принял новый файл slapd.conf. Это делается с помощью следующих команд:
# остановка и запуск OpenLDAP (slapd) # Linux/Redhat /etc/rc.d/init.d/ldap restart # BSD [bsd] /usr/local/etc/rc.d/slapd.sh stop # затем [bsd] /usr/local/etc/rc.d/slapd.sh start # убеждаемся, что slapd запущен ps ax | grep slapd
Теперь нам нужно проверить вновь установленную нами политику. Для проверки ACL используйте Ваш LDAP-браузер и следующие тесты:
Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=Robert Smith, ou=people, dc=example, dc=com с паролем (userpassword) rJsmitH (регистр символов имеет значение). Поскольку у данной записи есть привилегии hrpeople, её владелец сможет просматривать и изменять все записи, в том числе атрибуты carlicense, homepostaladdress и homephone, но не атрибут userpassword (за исключением своей собственной записи).
Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=Sheri Smith, ou=people, dc=example, dc=com с паролем (userpassword) sSmitH (регистр символов имеет значение). Поскольку у данной записи есть привилегии itpeople, её владелица сможет просматривать и изменять атрибут userpassword всех записей, не не сможет просматривать атрибуты carlicense, homepostaladdress и homephone какой-либо записи, за исключением своей собственной.
Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=John Smith, ou=people, dc=example, dc=com с паролем (userpassword) jSmitH (регистр символов имеет значение). Поскольку у данной записи нет привилегий, её владелец не сможет просматривать атрибуты carlicense, homepostaladdress, homephone и userpassword какой-либо записи, за исключением своей собственной (которую, также, сможет и модифицировать).
Настройте Ваш LDAP-браузер на анонимное подсоединение и убедитесь, что доступ запрещён.
Наконец, пройдите аутентификацию от имени настроенного нами rootdn или администратора (определён в slapd.conf как cn=jimbob,dc=example,dc=com, пароль dirtysecret) и убедитесь, что в этом случае игнорируются все наши привилегии и можно просматривать и изменять всё что угодно.
Примечание: Во всех приведённых выше тестах Вы должны быть в состоянии с помощью Вашего LDAP-браузера просматривать ветку groups и записи hrpeople и itpeople. Если этого не происходит, то, возможно, Вы установили значение Base DN (или Root DN) Вашего LDAP-браузера в ou=people,dc=example,dc=com. Установите его в dc=example,dc=com, и тогда Вы сможете просматривать (но не редактировать) ветку groups и её записи.
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 21 октября 2015 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2013 г.