Глава 5. Примеры OpenLDAP

Содержание

5.1 Простой каталог

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 Защита каталога

5.2.1 Политика безопасности
5.2.2 Добавление групп
5.2.3 ACL — директивы access файла slapd.conf
5.2.4 Тестирование ACL

5.3 Расширение иерархии

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 Отсылки и репликация

5.2.1 Политика безопасности

А теперь с помощью директив access в slapd.conf добавим к нашему каталогу несколько правил безопасности.

Мы собираемся строить политику контроля доступа (Access Control Policy, ACP, известную также как ACL) на основании корпоративной политики безопасности (круто!), которая гласит:

1. Владелец записи каталога имеет право просматривать ВСЕ атрибуты своей записи, включая пароли.

2. Сотрудники отдела Human Resources должны иметь право обновлять ЛЮБУЮ запись, но не должны иметь прав на чтение или запись паролей пользователей.

3. В записях каталога атрибуты carlicence, homepostaddress и homephone не должны быть доступны для чтения кому бы то ни было, за исключением сотрудников отдела Human Resources, а также владельца записи каталога.

4. Все пользователи должны проходить аутентификацию (анонимный доступ не разрешается).

5. Сотрудники отдела IT должны иметь право обновлять или изменять пароль записи во всех записях каталога.

Что бы Вы ни думали о такой политике, мы собираемся разрабатывать контроль доступа, воплощающий её в жизнь. Первое, что мы сделаем — это создадим две группы для hrpeople и itpeople, что позволит нам назначать групповые привилегии. Мы разместим эти группы в ветке groups, которая будет находиться в первом уровне иерархии сразу за корневой записью DIT. Приведённая ниже диаграмма показывает нашу новую структуру.

5.2.2 Добавление групп

Следующий 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

Чтобы получить данный пример в виде отдельного текстового файла, используйте эту ссылку и функцию сохранить как Вашего браузера.

Примечания:

1. Для определения группы мы использовали объектный класс groupOfNames.

2. member: dn определяет члена (членов) группы по их DN.

3. Наблюдательные (или до сих пор не заснувшие) читатели отметили, что в настоящий момент в нашем 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.

5.2.3 ACL — директивы access файла slapd.conf

Теперь нам нужно перевести нашу политику безопасности в списки контроля доступа (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

5.2.4 Тестирование ACL

Теперь нам нужно проверить вновь установленную нами политику. Для проверки ACL используйте Ваш LDAP-браузер и следующие тесты:

1. Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=Robert Smith, ou=people, dc=example, dc=com с паролем (userpassword) rJsmitH (регистр символов имеет значение). Поскольку у данной записи есть привилегии hrpeople, её владелец сможет просматривать и изменять все записи, в том числе атрибуты carlicense, homepostaladdress и homephone, но не атрибут userpassword (за исключением своей собственной записи).

2. Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=Sheri Smith, ou=people, dc=example, dc=com с паролем (userpassword) sSmitH (регистр символов имеет значение). Поскольку у данной записи есть привилегии itpeople, её владелица сможет просматривать и изменять атрибут userpassword всех записей, не не сможет просматривать атрибуты carlicense, homepostaladdress и homephone какой-либо записи, за исключением своей собственной.

3. Настройте Ваш LDAP-браузер на подсоединение с аутентификацией от имени dn: cn=John Smith, ou=people, dc=example, dc=com с паролем (userpassword) jSmitH (регистр символов имеет значение). Поскольку у данной записи нет привилегий, её владелец не сможет просматривать атрибуты carlicense, homepostaladdress, homephone и userpassword какой-либо записи, за исключением своей собственной (которую, также, сможет и модифицировать).

4. Настройте Ваш LDAP-браузер на анонимное подсоединение и убедитесь, что доступ запрещён.

5. Наконец, пройдите аутентификацию от имени настроенного нами 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 и её записи.