Глава 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.3.1 Расширение требований

Наша текущая реализация оказалась настолько чудесной, что руководители корпорации решили сделать ещё четыре улучшения:

1. Добавить общую адресную книгу клиентов и контактной информации, которая будет доступна для чтения всем прошедшим аутентификацию пользователям. Добавлять же в неё записи смогут только сотрудники отдела продаж (sales).

2. Предусмотреть возможность хранения сведений о всех IT-ресурсах компании (компьютерах, принтерах и т.д.) в каталоге. Эти сведения могут обновляться только членами группы itpeople, но будут доступны для чтения всем.

3. Добавить в каталог персональные адресные книги в виде дочерней к записи пользователя ветки addressbook. Записи в адресной книге могут быть созданы, прочитаны и изменены только самим пользователем — владельцем записи. Но сам пользователь не сможет удалить ветку addressbook своей записи (это смогут сделать только члены группы itpeople, которым не будет разрешено просматривать записи адресной книги).

4. Группа hrpeople будет отвечать за добавление и удаление записей во всех группах.

Пересмотренное DIT выглядит так:

5.3.2 Реализация расширения

После того, как нас обескуражили этими требованиями, нужно подумать о том, как их реализовать. Необходимо сделать следующее:

1. Добавить новую группу salespeople в нашу существующую ветку group.

2. Добавить новую ветку equipment в наше DIT. Записи в ней будут использовать объектный класс device.

3. Добавить новую ветку customers в наше DIT. Записи в ней будут использовать стандартный объектный класс inetorgperson.

4. Добавить новую ветку addressbook в каждую запись people. Записи в ней будут использовать стандартный объектный класс inetorgperson.

5.3.3 LDIF для реализации расширения

Следующий LDIF показывает, как мы изменили DIT согласно указанным выше требованиям:

version: 1

# Создаём ветку customers ПЕРВОГО уровня иерархии

dn: ou=customers,dc=example,dc=com
objectclass: organizationalunit
ou: customers
description: customer address book branch

# Создаём ветку equipment ПЕРВОГО уровня иерархии

dn: ou=equipment,dc=example,dc=com
objectclass: organizationalunit
ou: equipment
description: IT assets branch 

# создаём запись в equipment

dn: cn=LP1,ou=equipment,dc=example,dc=com
objectclass: device
cn: LP1
description: Some brand of printer
serialnumber: 1-77-23-15
l: Room 17
owner: cn=John Smith,ou=people,dc=example,dc=com
ou: printers

# создаём запись salespeople в groups

dn: cn=salespeople,ou=groups,dc=example,dc=com
objectclass: groupofnames
cn: salespeople
description: Sales group
member: cn=John Smith,ou=people,dc=example,dc=com

# создаём запись addressbook для каждого человека

dn: ou=addressbook,cn=John Smith,ou=people,dc=example,dc=com
objectclass: organizationalunit
ou: addressbook
description: Personal Address Book

dn: ou=addressbook,cn=Sheri Smith,ou=people,dc=example,dc=com
objectclass: organizationalunit
ou: addressbook
description: Personal Address Book

dn: ou=addressbook,cn=Robert Smith,ou=people,dc=example,dc=com
objectclass: organizationalunit
ou: addressbook
description: Personal Address Book

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

Примечание:

1. Мы создали одну запись в equipment.

Предположим, что мы сохранили приведённый выше LDIF как enhance.ldif в директории /tmp. Тогда мы будем загружать LDIF-файл с помощью примерно такого вызова ldapadd (приведённая ниже команда разбита на две строки только из соображений форматирования HTML и должна записываться в одну строку):

ldapadd -H ldap://ldaphost.example.com -x -D "cn=jimbob,dc=example,dc=com" 
 -f /tmp/enhance.ldif -w dirtysecret

Замените ldaphost.example.com на имя того хоста, на котором располагается Ваш каталог LDAP.

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

Теперь нам нужно перевести наши обновления политики безопасности в списки контроля доступа (Access Control List, ACL), используя директивы access to файла slapd.conf OpenLDAP.

Управление доступом к персональной адресной книге — очень сложное обновление, которое мы описали в умопомрачительных подробностях здесь. В данном примере используются те же списки ACL, что описаны нами на предыдущем шаге, за исключением того, что мы добавили ACL8A для контроля доступа к разделу equipment, разобраться в котором несложно после чтения комментариев к предыдущим ACL.

Примечание: Значимые изменения были внесены в этот файл после повторного запуска этих тестов на OpenLDAP версии 2.4.16+. Обратите внимание.

В листинге ниже приводится наш оригинальный пример slapd.conf с изменениями, включающими нашу политику контроля доступа.

#
###### ПРИМЕР 2 — КАТАЛОГ С УЛУЧШЕННЫМИ ACL ############
#
# Примечание: inetorgperson использует атрибуты и
#     объектные классы из всех трёх наборов схемы
#     объектный класс device определён в core.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

# НЕТ ОТСЫЛОК

# НЕ заботимся о файле 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"
# Примечания к ACL
# Эти дополнительные примечания относятся к OpenLDAP версии 2.4:
# 1. В настоящий момент используется ключевое слово attrs вместо attr
#   (это позволяет уменьшить количество предупреждающих сообщений).
# 2. При использовании регулярных выражений нужно удалить модификатор expand, 
#    поскольку OpenLDAP 2.4 отклоняет некоторые (но не все) ACL,
#    содержащие этот модификатор.
# 3. Проверки, производимые OpenLDAP 2.4, гораздо более жесткие,
#    они отклоняют ACL 8, так как в нём содержатся атрибуты,
#    которые будут добавлены позже.
# 4. Если в условии by используется ключевое слово exact и
#    замена с применением регулярного выражения,
#    то должен использоваться модификатор expand.
# 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
# разрешаем читать 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 или ACL6A) и дочерние (CHILDREN) записи данной записи (ACL4)
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   attrs=children
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# ACL5 — требуется только до версии 2.2
# разрешаем создание записей в своей addressbook;
# остальные не могут получить к ней доступ, требуются права на запись
# в атрибут ENTRY (ACL5 или ACL6A) и дочерние (CHILDREN) записи данной записи (ACL4)
#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" write
#  by users none

# ACL6 — требуется только до версии 2.2
# разрешаем создание записей в своей addressbook;
# остальные не могут получить к ней доступ
#access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
#   filter=(objectclass=inetorgperson)
#  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
#  by users none

# ACL6A — в версиях 2.2+ сразу два ACL, — ACL5 и ACL6, — заменяются данным ACL
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   attrs=entry,@inetorgperson
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# ACL7
# разрешаем sales создание записей в customers
# пользователи, прошедшие аутентификацию получают доступ только на чтение
access to dn.one="ou=customers,dc=example,dc=com"
   attrs=children
  by group.exact="cn=salespeople,ou=groups,dc=example,dc=com" write
  by users read

# ACL8
access to attrs=carlicense,homepostaladdress,homephone
  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

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

Теперь нам нужно остановить и снова запустить 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/openldap/slapd.sh start

# убеждаемся, что slapd запущен
ps ax | grep slapd

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

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

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

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

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

4. Поэксперементируйте с добавлением записей в разные адресные книги, — общую и частные, — либо с помощью LDIF, либо с помощью Вашего LDAP-браузера.

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

6. Пройдите аутентификацию от имени настроенного нами rootdn или администратора (определён в slapd.conf как cn=jimbob,dc=example,dc=com, пароль dirtysecret) и убедитесь, что в этом случае игнорируются все наши привилегии и можно просматривать и изменять всё что угодно.

7. На данном этапе может быть полезно экспортировать текущее состояние каталога в LDIF с помощью функции экспорта Вашего LDAP-браузера, либо slapcat.

Примечание: Во всех приведённых выше тестах Вы должны быть в состоянии с помощью Вашего LDAP-браузера просматривать ветки customers, equipment и groups, а также записи в них. Если этого не происходит, то, вероятно, Вы установили значение Base DN (или Root DN) Вашего LDAP-браузера в ou=people,dc=example,dc=com. Установите его в dc=example,dc=com и тогда Вы сможете просматривать все эти записи.