Перейти к содержанию

Настройка LDAPS/StartTLS для OpenLDAP#

Введение#

В этом примере будет показана пошаговая настройка LDAP сервера на ОС Debian 10 "buster". Для других Linux дистрибутивов отличие может быть лишь в расположении конфигурационных файлов, а также в командах по установке необходимых пакетов.

В тексте используется следующее общепринятое соглашение перед листингом команд:

  • команды после символа # выполняются от имени root.
  • команды после символа $ выполняются от обычного пользователя.

Установка необходимых пакетов#

Установка всех пакетов производится на один сервер. Этот сервер объединяет в себе роли DNS и LDAP-сервера. Дополнительно на нем будет развернут Удостоверяющий Центр (УЦ) для выпуска сертификатов, используемых в TLS-соединении. В реальном применении рекомендуется разнесение каждой из этих ролей на отдельные серверы.

Список необходимых пакетов для установки представлен в таблице ниже:

Название пакета Описание
dnsmasq Пакет, который позволяет настраивать DNS, DHCP и TFTP-сервера. В примере используется только DNS-сервер.
slapd Демон, обеспечивающий функции LDAP-сервера, входящий в проект OpenLDAP.
ldap-utils Набор утилит, используемых для взаимодействия с LDAP-сервером для конфигурации и просмотра информации.

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

1
# apt install dnsmasq slapd ldap-utils

В процессе установки будет предложено установить пароль администратора LDAP. В дальнейшем этот пароль будет изменен с помощью утилиты slappasswd.

1

Установка пароля

Начальная конфигурация#

Настройка статического IP-адреса#

Перед настройкой сервисов необходимо задать статический IP-адрес на сервере. Для этого на интерфейсе, который подключен в локальную сеть, установите следующие настройки:

  • IP address: 192.168.122.250
  • Netmask: 255.255.255.0
  • Default Gateway: 192.168.122.1

Настройка DNS-сервера#

Необходимость использования отдельного локального DNS-сервера связана с тем, что для проверки подлинности серверного сертификата при установлении TLS-соединения производится проверка подлинности сертификата.

В Numa Edge за проверку подлинности сертификата отвечает параметр

1
system ldap-server tls-server-auth

который по умолчанию установлен в значение enable. Отключение проверки подлинности сертификата строго не рекомендуется.

Проверка подлинности осуществляется путем поиска соответствия IP-адреса и DNS-имени LDAP-сервера со значениями полей subjectAltName и CN-сертификата, который сервер передает клиенту в сообщении Server Hello при установлении TLS-соединения.

Поскольку выпуск сертификата со значением CN равным IP-адресу LDAP-сервера существенно сокращает гибкость применения такой схемы, для CN рекомендуется задавать именно DNS-имя. Следующим соображением является то, что в случае масштабируемости схемы и добавлении нескольких LDAP-клиентов, на каждом из них необходимо будет поддерживать статические DNS-записи в актуальном состоянии.

Данные факты приводят к необходимости настройки отдельного локального DNS-сервера.

Конфигурация DNS-сервера представлена в листинге ниже. Хорошей идеей является создание отдельного конфигурационного файла в каталоге /etc/dnsmasq.d/, вместо редактирования стандартного /etc/dnsmasq.conf.

Создайте файл /etc/dnsmasq.d/dns.conf, в котором укажите следующие директивы:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# Выключить DHCP сервер 
no-dhcp-interface=ens3
#Адрес, которые слушает DNS сервер 
listen-address=::1,127.0.0.1,192.168.122.250
#Описание домена 
domain=openldap.local,192.168.122.0/24
#Описание DNS зоны и авторитетного сервера для этой зоны
auth-zone=openldap.local
auth-server=dc1.openldap.local
#Не использовать конфигурационные файлы /etc/hostname и /etc/resolv.conf
no-hosts
no-resolv
#Создание статических записей 
host-record=ldap.openldap.local,192.168.122.250
host-record=dns.openldap.local,192.168.122.250
host-record=edge.openldap.local,192.168.122.100


# Вышестоящий DNS сервер
server=8.8.8.8

Протестировать конфигурацию на наличие синтаксических ошибок перед запуском можно с помощью команды

1
2
# dnsmasq --test
dnsmasq: syntax check OK.

Далее необходимо настроить обработку внутренних DNS-запросов через локальный DNS-сервер:

1
2
# cat /etc/resolv.conf 
nameserver 127.0.0.1

Теперь необходимо перезапустить службу dnsmasq:

1
# service dnsmasq restart

Настройка LDAP-сервера#

Настройка LDAP-сервера будет осуществляться с помощью метода динамической конфигурации времени исполнения (OLC, On-Line Configuration). Данный метод позволяет изменять конфигурации без необходимости остановки и перезапуска демона slapd.

Изменения вносятся в специальное информационное дерево каталогов (directory information tree, DIT) с жестко привязанным значением cn=config. Необходимые изменения вносятся в специальный файл формата LDIF (LDAP Data Interchange Format), который затем добавляется на LDAP-сервер с помощью утилит из пакета ldap-utils.

После первоначальной настройки и во время эксплуатации более удобным способом для внесения небольших изменений является использование LDAP-браузеров (Apache Directory Studio, Kldap и др).

Инициализация конфигурации каталога#

Перед началом настройки будет удобно создать отдельный каталог, в котором будут храниться LDIF-файлы:

1
2
mkdir ~/ldap
cd ~/ldap

Сохраним содержимое стандартных каталогов slapd перед внесением изменений в каталог с тем же названием, добавив приписку .bcp:

1
2
3
#  service slapd stop
#  mv /etc/ldap/slapd.d{,.bcp}
#  mv /var/lib/ldap{,.bcp}

Создадим пустой каталог для нашей новой конфигурации:

1
# mkdir /etc/ldap/slapd.d

Создадим файл init-config.ldif с новой конфигурацией и запишем в него:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
dn: cn=config
objectClass: olcGlobal
cn: config
olcPidFile: /var/run/slapd/slapd.pid
olcArgsFile: /var/run/slapd/slapd.args

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: to *
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage

dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

В этом файле для начала указывается корневая запись DIT, которая, как было сказано ранее, необходима для метода OLC. С помощью директив olcPidFile и olcArgsFile указывается куда необходимо записать ID процесса службы каталогов и аргументы его запуска соответственно.

Далее задается служебная база данных конфигурации cn=config. Также добавляется правило доступа (ACL, Access Control List), разрешающее манипулировать ей от имени пользователя root (uid=0, gid=0) с помощью механизма SASL EXTERNAL и идентификационной сущности IPC. Необходимо помнить, что в конце каждого ACL, если не задан модификатор break, подразумевается наличие правила by * none. То есть остальной доступ к объекту в условии to – запрещён.

Инициализируем конфигурацию с помощью команды:

1
2
3
# slapadd -n 0 -F /etc/ldap/slapd.d -l init-config.ldif
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...

Модификатор -n 0 говорит о том, что мы добавляем данные в базу данных с индексом 0, который зарезервирован для cn=config. Если его не указать, slapadd по умолчанию будет пытаться добавить данные в первую базу данных с индексом больше нуля (обычно это первая по списку пользовательская база данных).

Примечание

Утилиты slapadd и ldapadd выполняют одни и те же функции по добавлению новых записей в каталог LDAP, однако имеют два важных отличия: Все утилиты OpenLDAP, название которых начинается с slap, работают только локально на LDAP-сервере. Утилиты, начинающиеся с ldap, работают через протокол LDAP и могут работать по сети. Перед внесением изменений с помощью с утилит, начинающихся с slap, необходимо ОБЯЗАТЕЛЬНО остановить демон slapd.

Проверить на ошибки конфигурацию можно с помощью команды:

1
2
#  slaptest -uF /etc/ldap/slapd.d
config file testing succeeded

Последним этапом первоначальной настройки является изменения прав доступа для каталога slapd, который был создан ранее из-под пользователя root.

1
2
#  chown -R openldap:openldap /etc/ldap/slapd.d
#  chmod 750 /etc/ldap/slapd.d

Запуск службы каталогов#

Теперь можно запустить демон slapd с помощью команды:

1
#  service slapd start

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

1
2
3
4
5
6
7
8
# journalctl -u slapd -n 5
-- Logs begin at Thu 2021-07-08 15:42:05 MSK, end at Thu 2021-07-08 15:46:21 MSK. --
Jul 08 15:46:21 dc1 systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
Jul 08 15:46:21 dc1 slapd[639]: @(#) $OpenLDAP: slapd  (Feb 14 2021 18:32:34) $
                                        Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
Jul 08 15:46:21 dc1 slapd[640]: slapd starting
Jul 08 15:46:21 dc1 slapd[634]: Starting OpenLDAP: slapd.
Jul 08 15:46:21 dc1 systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)

Убедимся, что процесс slapd "слушает" порт TCP/389.

1
2
3
# ss -tlnp | grep 389
LISTEN    0         128                0.0.0.0:389              0.0.0.0:*        users:(("slapd",pid=593,fd=8))  
LISTEN    0         128                   [::]:389                 [::]:*        users:(("slapd",pid=593,fd=9))

Убедимся, что UNIX-сокет тоже активен:

1
2
# ss -xa | grep ldap
u_str LISTEN 0      128               /var/run/slapd/ldapi 21863              * 0

И проверим ранее добавленную конфигурацию OLC с помощью утилиты ldapsearch:

1
2
3
4
5
# ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'cn=config' dn
dn: cn=config
dn: cn=schema,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config

Краткое описание аргументов команды:

1
ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'cn=config' dn

представлено ниже:

  • -Q – не выводит служебную информацию режима SASL
  • -LLL – не выводит служебную информацию LDIF
  • -Y EXTERNAL вместе с аргументом -H ldapi:/// указывают на использование аутентификации с помощью механизма межпроцессорного взаимодействия (Unix IPC)
  • -b 'cn=config' – где производится поиск
  • dn – записи какого типа найти

Подключение динамических модулей#

Для корректной работы необходимо два модуля. Один – для механизма базы данных mdb (Memory-Mapped Database, отображаемая в памяти базы данных), который оптимизирован для выполнения операций чтения. Второй модуль – monitor, для создания и динамической поддержки ветки с информацией о текущем статусе демона slapd.

Чтобы их подключить создается LDIF-файл, в котором описываются изменения каталога cn=module,cn=config. Пусть файл будет назван add-modules.ldif со следующим содержимым:

1
2
3
4
5
6
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: back_mdb.la
olcModuleLoad: back_monitor.la

В атрибуте olcModulePath указывается путь до модулей, хранящихся файловой системе. В атрибуте olcModuleLoad – название подключаемых модулей, относительно данного каталога.

Добавим наш LDIF-файл в конфигурацию:

1
2
# ldapadd -QY EXTERNAL -H ldapi:/// -f add-modules.ldif
adding new entry "cn=module,cn=config"

Добавление наборов схем данных#

Схемы данных представляют собой коллекции атрибутов и объектных классов, которые будут использоваться при создании записей в каталогах LDAP. С пакетом OpenLDAP поставляется большой набор схем данных, которые хранятся в каталоге /etc/ldap/schema/, однако по умолчанию они не используются и их необходимо добавлять вручную. Для этого создадим LDIF-файл с необходимыми нам наборами схем данных. Порядок их следования в файле очень важен! Атрибуты наборов схем иерархически связаны и требуют их объявления с соблюдением иерархии.

Примечание

Если в результате добавления нового атрибута будет возвращена ошибка, описанная ниже: 

1
2
3
LDAP result code: 17 (Undefined attribute type)

The requested operation failed because it referenced an attribute that is not defined in the server schema.
то это значит, что производится попытка добавления атрибута, для которого отсутствует добавленная схема данных. В таком случае необходимо добавить требуемую схему данных для указанного атрибута.

В таблице ниже приведена информация об используемых схемах данных.

Файл схемы данных Описание
core.ldif Базовая схема данных, которая является обязательной для добавления.
cosine.ldif Набор классов и атрибутов, использующий спецификацию Cosine и Internet X.500. Описан в RFC 4524.
nis.ldif Применяется для отображения TCP/IP и UNIX атрибутов в формат X.500. Описан RFC 2307.
inetorgperson.ldif Описывает расширенные пользовательские атрибуты, такие как uid, mail,display name и т.д. Описан в RFC 2798.

Схемы данных, распространяемые с пакетом OpenLDAP, хранятся в каталоге /etc/ldap/schema. Создадим файл add-schemas.ldif и запишем в него абсолютные пути до требуемых схем данных:

1
2
3
4
include: file:///etc/ldap/schema/core.ldif
include: file:///etc/ldap/schema/cosine.ldif
include: file:///etc/ldap/schema/nis.ldif
include: file:///etc/ldap/schema/inetorgperson.ldif

Добавьте схемы данных:

1
2
3
4
5
# ldapadd -QY EXTERNAL -H ldapi:/// -f add-schemas.ldif
adding new entry "cn=core,cn=schema,cn=config"
adding new entry "cn=cosine,cn=schema,cn=config"
adding new entry "cn=nis,cn=schema,cn=config"
adding new entry "cn=inetorgperson,cn=schema,cn=config"

И проверьте корректность их добавления:

1
2
3
4
5
# ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -D  cn=config -b cn=schema,cn=config -s one 1.1
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config

Команде ldapsearch, помимо уже используемых ранее параметров, передаются -s one, для которого возвращает записи на один уровень ниже записи в параметре -b, а 1.1 указывает, что необходимо вернуть только записи без атрибутов.

Примечание

Обратите внимание, что после добавления схем, каждой из них был присвоен номер в формате cn={Z}xxx,cn=schema,cn=config, где {Z} — числовой счётчик, нумерация которого начинается с 0, а xxxx — имя набора схемы данных. Нумерация производится в порядке добавления, таким образом схема core имеет значение 0, cosine – 1 и т.д. Если вы захотите дополнительно добавить еще одну схему, ей будет присвоен следующий свободный номер. Если попытаться добавить новую схему, явно указав порядковый номер, то в зависимости от того, как сформирован LDIF-файл и какая утилита используется, возможна как и замена существующей записи, так и получение ошибки при добавлении. Подобный пример будет продемонстрирован в дальнейшем.

Инициализация базы данных#

После подготовки конфигурации произведите настройку самой базы данных LDAP.

Первоначально измените пароль администратора, который был задан при установке. Для этого воспользуйтесь утилитой slappasswd, которая генерирует посоленный хеш вводимого пароля, используя алгоритм SHA-1.

1
2
3
4
# slappasswd
New password: 
Re-enter new password: 
{SSHA}3qa/W7xnBNFGbOSMY6xmrqCSXu7RRHdT

Полученный хеш необходимо добавить в атрибут olcRootPW конфигурационного LDIF-файл базы данных db.ldif.

Другими атрибутами, заслуживающими внимания, являются:

  • olcDatabase – используется ранее добавленный модуль mdb;
  • olcSuffix – корневая запись DIT, значением которой является имя домена DNS;
  • olcDbDirectory – путь к каталогу базы данных в файловой системе. Данный атрибут является обязательным и требует существования каталога на момент загрузки конфигурации;
  • olcDbMaxsize – еще один обязательный атрибут, требующий задания максимального размера базы данных. В файловой системе должно быть достаточно свободного места для размещения базы данных такого размера;
  • olcRootDN – DN администратора базы данных. Этот пользователь обладает полным доступом ко всей базе данных, поэтому необходимо надежно хранить его пароль;
  • olcAccess – атрибут описывающий правила доступа к базе данных:
  • Доступ ко всей базе данных (to *):
    • Разрешить доступ пользователю root с использованием механизма SASL EXTERNAL.
    • Продолжить анализ ACL, если нет совпадений с субъектами доступа, указанными с помощью директивы by.
  • Доступ к атрибуту userPassword (to attrs=userPassword):
    • Разрешить доступ для смены пароля самим пользователем.
    • Разрешить доступ для аутентификации.
  • Доступ к остальной базе данных:
    • Разрешить пользователям просматривать свои записи.

Далее через пустую строку описывается еще один ранее добавленный модуль monitor.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
dn: olcDatabase=mdb,cn=config
objectClass: olcMdbConfig
olcDatabase: mdb
olcSuffix: dc=openldap,dc=local
olcDbDirectory: /var/lib/ldap
olcDbMaxsize: 1073741824
olcRootDN: cn=admin,dc=openldap,dc=local
olcRootPW: {SSHA}3qa/W7xnBNFGbOSMY6xmrqCSXu7RRHdT
olcAccess: {0}to *
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
  by * break
olcAccess: {1}to attrs=userPassword
  by self write
  by anonymous auth
olcAccess: {2}to *
  by self read

dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: monitor

Для базы данных необходимо создать каталог и задать ему права доступа:

1
2
3
#  mkdir /var/lib/ldap
#  chown openldap:openldap /var/lib/ldap 
#  chmod 0700 /var/lib/ldap

Загрузите конфигурацию базы данных:

1
2
3
#  ldapadd -QY EXTERNAL -H ldapi:/// -f db.ldif
adding new entry "olcDatabase=mdb,cn=config"
adding new entry "olcDatabase=monitor,cn=config"

Определите RootDN для доступа к конфигурации службы каталогов. Он будет ссылаться на RootDN, находящийся в данной БД. Эта запись желательна только при первоначальной настройке или в тестовой конфигурации. Не оставляйте её в "боевой" системе! Для {-1}frontend задайте минимально необходимые права для доступа к RootDSE. Создадим LDIF-файл acl-mod.ldif, модифицирующий права доступа:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootDN
olcRootDN: cn=admin,dc=openldap,dc=local

dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to *
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
  by * break
olcAccess: {1}to dn.base=""
  by * read
olcAccess: {2}to dn.base="cn=subschema"
  by * read

Загрузите LDIF, изменяющий ACL:

1
2
3
4
#  ldapadd -QY EXTERNAL -H ldapi:/// -f acl-mod.ldif
modifying entry "olcDatabase={0}config,cn=config"

modifying entry "olcDatabase={-1}frontend,cn=config"

Действия выше еще больше повысили значимость учётной записи администратора. С её помощью теперь можно получить полный доступ к службе каталогов.

Проверьте корректность всех ACL и, заодно, наличие всех добавленных данных (вывод отформатирован для наглядности):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#  ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'cn=config' dn olcAccess
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config

dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read

dn: olcDatabase={0}config,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth" manage

dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth" manage by * break
olcAccess: {1}to attrs=userPassword by self write by anonymous auth
olcAccess: {2}to * by self read

dn: olcDatabase={2}monitor,cn=config

Убедитесь, что учётная запись администратора имеет доступ службе каталогов:

1
2
3
$  ldapwhoami -WD cn=admin,dc=openldap,dc=local
Enter LDAP Password:
dn:cn=admin,dc=openldap,dc=local

Если полученный результат соответствует приведенному выше, то LDAP-сервер настроен корректно.

Отредактируйте файл /etc/ldap/ldap.conf. Это нужно только для того, чтобы немного упростить себе жизнь и меньше печатать в дальнейшем. В BASE подставьте свой суффикс, а в URI – FQDN Вашего сервера OpenLDAP:

1
2
3
4
5
6
BASE  dc=openldap,dc=local
URI  ldap://ldap.openldap.local

$ ldapsearch -LLLWD cn=admin,dc=openldap,dc=local -b cn=config -s base dn
Enter LDAP Password: 
dn: cn=config

Теперь необходимо наполнить базу данных LDAP-сервера полезной информацией, а именно задать пользователей и группы.

Добавление пользователей и групп в OpenLDAP#

Необходимо создать файл LDIF с именем add_content.ldif. Пожалуй, содержимое данного файла является самым большим во всей инструкции. Первая сущность описывает корневой суффикс базы данных (DIT), которая имеет значение dc=openldap,dc=local. Далее создаются две организационные единицы (Organizational Unit, OU) для хранения пользователей и групп.

Затем создаются три пользователя:

  • uid=john, userPassword=test
  • uid=oper, userPassword=oper

  • uid=test, userPassword=test#

Задается пароль для всех пользователей указывается в открытом виде, но в дальнейшем для пользователя oper будет изменен на хешированное значение с помощью утилиты ldappasswd.

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

  • sn
  • givenName
  • cn
  • displayName
  • uidNumber
  • gidNumber
  • gecos
  • loginShell

  • homeDirectory#

Содержимое файла add_content.ldif представлено ниже.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
dn: dc=openldap,dc=local
dc: openldap
objectClass: top
objectClass: domain

dn: ou=People,dc=openldap,dc=local
objectClass: organizationalUnit
ou: People

dn: ou=Groups,dc=openldap,dc=local
objectClass: organizationalUnit
ou: Groups

dn: uid=john,ou=People,dc=openldap,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: john
sn: Doe
givenName: John
cn: John Doe
displayName: John Doe
uidNumber: 10000
gidNumber: 5000
userPassword: test
gecos: John Doe
loginShell: /bin/bash
homeDirectory: /home/john

dn: uid=test,ou=People,dc=openldap,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: test
sn: user
givenName: test
cn: test user
displayName: test user
uidNumber: 10001
gidNumber: 5001
userPassword: test
gecos: test user
loginShell: /bin/bash
homeDirectory: /home/test

dn: uid=oper,ou=People,dc=openldap,dc=local
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: oper
sn: user
givenName: oper
cn: oper user
displayName: oper user
uidNumber: 10002
gidNumber: 5002
userPassword: oper
gecos: oper user
loginShell: /bin/bash
homeDirectory: /home/oper

Добавьте данную конфигурацию с помощью команды ldapadd следующим образом:

1
# ldapadd -QY EXTERNAL -H ldapi:/// -f add_content.ldif

В случае успеха, будет получен следующий вывод на консоль:

1
2
3
4
5
6
7
ldapadd -QY EXTERNAL -H ldapi:/// -f add_content.ldif
adding new entry "dc=openldap,dc=local"
adding new entry "ou=People,dc=openldap,dc=local"
adding new entry "ou=Groups,dc=openldap,dc=local"
adding new entry "uid=john,ou=People,dc=openldap,dc=local"
adding new entry "uid=test,ou=People,dc=openldap,dc=local"
adding new entry "uid=oper,ou=People,dc=openldap,dc=local"

Репозиторий NFS netgroup на основе OpenLDAP#

Для того чтобы проходить аутентификацию на Numa Edge, используя учетные данные LDAP-сервера, необходимо добавить еще одну сущность: netgroup.

В настоящий момент в Numa Edge существуют следующие ограничения:

  • для пользователя обязательно должен быть указан домашний каталог (homeDirectory);
  • значение uidNumber должно быть больше 10000;
  • если пользователь принадлежит netgroup с названием edge-admin, после аутентификации данный пользователь будет иметь права администратора на Numa Edge;

  • если пользователь принадлежит netgroup с названием edge-op, после аутентификации данный пользователь будет иметь права оператора на Numa Edge.#

Перед добавлением, необходимо убедиться в наличии схемы NIS, внутри которой содержатся классы netgroup.

1
2
# ldapsearch -QLLL -Y EXTERNAL -H ldapi:// -b cn=schema,cn=config dn | grep nis
dn: cn={2}nis,cn=schema,cn=config

Проверим содержимое самой схемы для подтверждения утверждения, описанного выше.

1
2
3
4
# ldapsearch -LLLQ -Y EXTERNAL -H ldapi://  -b cn={2}nis,cn=schema,cn=config | grep NAME | cut -d' ' -f5 | grep -i netgroup
'memberNisNetgroup'
'nisNetgroupTriple'
'nisNetgroup'

Теперь необходимо создать LDIF-файл, в котором будет добавлен атрибут nisNetgroupTriple. Данный атрибут имеет следующий формат:

1
(<host>, <user>, <domain>)

В данном примере не будет ограничена возможность пользователя подключаться только к определенным хостам или доменам, поэтому значения данных полей будут оставлены пустыми. Для добавления пользователя john в netgoup со значением edge-admin, создайте следующий LDIF-файл.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
dn: ou=netgroup,ou=Groups,dc=openldap,dc=local
ou: netgroup
objectClass: top
objectClass: organizationalUnit
description: NFS Netgroups


dn: cn=edge-admin,ou=netgroup,ou=Groups,dc=openldap,dc=local
objectClass: top
objectClass: nisNetgroup
cn: oracle
nisNetgroupTriple: (,john,)

dn: cn=edge-op,ou=netgroup,ou=Groups,dc=openldap,dc=local
objectClass: top
objectClass: nisNetgroup
cn: oracle
nisNetgroupTriple: (,oper,)

Теперь необходимо загрузить данную конфигурацию на LDAP-сервер.

1
ldapadd -QY EXTERNAL -H ldapi:/// -f netgroup.ldif

В случае успеха будет следующий результат:

1
2
3
4
ldapadd -QY EXTERNAL -H ldapi:/// -f netgroup.ldif
adding new entry "ou=netgroup,ou=Groups,dc=openldap,dc=local"
adding new entry "cn=edge-admin,ou=netgroup,ou=Groups,dc=openldap,dc=local"
adding new entry "cn=edge-op,ou=netgroup,ou=Groups,dc=openldap,dc=local"

Настройка контроля доступа#

Следующим этапом конфигурации будет включение анонимного доступа для чтения базы пользователей и групп. Данный метод имеет как свои недостатки, так и достоинства. К минусам можно отнести то, что потенциально любой находящийся в сети предприятия пользователь может узнать полный перечень ее сотрудников, включая информацию о паролях. Для устранения этого недостатка рекомендуется настроить шифрование LDAP-трафика с помощью TLS. А вот отсутствие необходимости использовать учетные данные администратора LDAP для доступа к каталогу, и настройка этих учетных данных на Numa Edge – является большим плюсом. В целом же данная конфигурация является опциональной и решение о ее применении должно приниматься согласно политике безопасности внутри организации.

Первоначально, узнайте текущую конфигурацию доступа к базе LDAP с помощью данной команды:

1
# ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'olcDatabase={1}mdb,cn=config' dn olcAccess

На текущий момент администратор LDAP имеет полный доступ к системе, а остальные авторизированные пользователи могут только изменять свой пароль.

1
2
3
4
5
ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'olcDatabase={1}mdb,cn=config' dn olcAccess
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth" manage by * break
olcAccess: {1}to attrs=userPassword by self write by anonymous auth

Файл anonimous-bind.ldif задает возможность чтения содержимого пользователей и групп без аутентификации. Поскольку каждой сущности olcAccess присваивается номер, согласно порядку ее добавления, необходимо удалить существующую под номером 1 и только после этого добавить новые.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
ldapmodify -QY EXTERNAL -H ldapi:/// -f  anonimous-bind.ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to dn.subtree="ou=People,dc=openldap,dc=local" by * read
olcAccess: {2}to dn.subtree="ou=Groups,dc=openldap,dc=local" by * read
olcAccess: {3}to attrs=userPassword by self write by anonymous auth
olcAccess: {4}to * by self read

Измените конфигурацию доступа к базе LDAP с помощью следующей команды:

1
ldapmodify -QY EXTERNAL -H ldapi:/// -f  anonimous-bind.ldif

И проверьте успешность применения конфигурации:

1
2
3
4
5
6
7
8
ldapsearch -QLLL -Y EXTERNAL -H ldapi:/// -b 'olcDatabase={1}mdb,cn=config' dn olcAccess
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth" manage by * break
olcAccess: {1}to dn.subtree="ou=People,dc=openldap,dc=local" by * read
olcAccess: {2}to dn.subtree="ou=Groups,dc=openldap,dc=local" by * read
olcAccess: {3}to attrs=userPassword by self write by anonymous auth
olcAccess: {4}to * by self read

Включение поддержки StartTLS LDAP#

Удостоверяющий центр на основе самоподписанного сертификата с помощью OpenSSL#

Для шифрования данных с помощью TLS используется механизм StartTLS, который работает на порту TCP/389. Механизм LDAPS признан устаревшим в RFC2830, хоть и широко используется. Numa Edge не поддерживает механизм LDAPS.

В целом, для обеспечения шифрования данных можно использовать сертификаты, сгенерированные на стороннем сервере УЦ и импортированных на LDAP-сервер и Numa Edge. Но в данном примере рассмотрим генерацию сертификатов на самом LDAP-сервере.

Создание УЦ#

Первоначально необходимо сгенерировать ключ УЦ в формате RSA и размером 2048 бит.

1
# openssl genrsa -out ca.key 2048

Далее необходимо создать конфигурационный файл certCA.conf с описанием полей сертификата УЦ:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = RU
ST = SZFO
L = Saint-Petersburg
O = Private
OU = engineeers
CN = ldap-ca
[v3_req]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = CA:true
keyUsage = cRLSign, keyCertSign

Теперь необходимо сгенерировать сам сертификат:

1
# openssl req -x509 -new -nodes -key ca.key -sha256 -days 1800 -config certCA.conf -extensions v3_req -out ca.crt

Создание сертификата сервера LDAP#

Теперь необходимо создать ключ сертификата, используемого LDAP-сервером:

1
# openssl genrsa -out ldap.key 2048

Конфигурационный файл certLDAP.conf для сертификата будет следующий:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = RU
ST = SZFO
L = Saint-Petersburg
O = Private
OU = engineeers
CN = ldap-server
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS = ldap.openldap.local

Первоначально необходимо создать запрос на выпуск сертификата. В реальном использовании генерация ключа должна производиться только на том сервере, где будет использоваться сертификат, а на УЦ передаваться только запрос на выпуск сертификата.

1
# openssl req -new -key ldap.key -config certLDAP.conf -reqexts 'v3_req' -out ldap.csr

И выпустим конечный сертификат, согласно полученному запросу.

1
# openssl x509 -req -in ldap.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out ldap.crt -days 360 -sha256 -extfile certLDAP.conf -extensions v3_req

Теперь необходимо создать каталог, в котором будет храниться ключ и сертификат LDAP-сервера, и изменить права на данном каталоге.

1
2
3
# mkdir /etc/ldap/ssl
# cp /root/ldap/ldap{.key,.crt} /etc/ldap/ssl/ 
# chown -R openldap:openldap /etc/ldap/ssl/

Создание сертификата клиента для Numa Edge#

Поскольку ранее было отключено требование на аутентификацию для просмотра содержимого пользователя и групп, то необходимо обеспечить другой метод сохранности этих данных. Для этого сгенерируем сертификат клиента, который будет использоваться при установлении TLS-соединения. В настройках LDAP-сервера далее будет указан атрибут, который будет отвергать соединения без валидного сертификата. Аналогично предыдущему примеру генерируется закрытый ключ клиента:

1
# openssl genrsa -out edge.key 2048

Конфигурационный файл certLDAP_edge.conf для сертификата будет выглядеть следующим образом (основное отличие – это X509-расширения, необходимые для клиентской стороны).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = RU
ST = SZFO
L = Saint-Petersburg
O = Private
OU = engineeers
CN = Numa Edge
[v3_req]
keyUsage = digitalSignature, keyAgreement
extendedKeyUsage = clientAuth
subjectAltName = @alt_names
[alt_names]
DNS = edge.openldap.local

Далее необходимо сгенерировать запрос на выпуск сертификата:

1
openssl req -new -key edge.key -config certLDAP_edge.conf -reqexts 'v3_req' -out edge.csr

И на его основе выпустить сертификат:

1
openssl x509 -req -in edge.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out edge.crt -days 360 -sha256 -extfile certLDAP_edge.conf -extensions v3_req

Теперь данные файлы необходимо скопировать на Numa Edge любым удобным способом. Важно помнить, что при передаче закрытого ключа необходимо использовать только надежные каналы передачи данных. Созданные файлы необходимо импортировать на Numa Edge:

1
2
3
4
5
6
7
admin@edge:~$ pki import from ca.crt
Импортируется сертификат УЦ ldap-ca как ca
admin@edge:~$ pki import from edge.crt
Импортируется сертификат Numa Edge как edge
W: Сертификат конечного объекта edge-ldap не имеет ключа
admin@edge:~$ pki import from edge.key
Импортируется ключ для Numa Edge

Далее создать конфигурационный файл tls-config.ldif, в котором будет описано расположение сертификатов и закрытого ключа, необходимое для работы StartTLS (Их нужно скопировать в папки как указано в конфигурационном файле ниже). Атрибут olcTLSVerifyClient описывает требования к клиентскому сертификату. В данном случае значение demand указывает, что если сертификат не был представлен или не прошел проверку, необходимо оборвать соединение.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
dn: cn=config
add: olcTLSVerifyClient
olcTLSVerifyClient: demand
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ldap.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ca.crt

Загрузите данную конфигурацию на LDAP-сервер:

1
2
ldapmodify -QY EXTERNAL -H ldapi:/// -f tls-config.ldif
modifying entry "cn=config"

Настройки Edge#

Конфигурация для подключения к LDAP-серверу и использования данных с LDAP для аутентификации на Numa Edge выглядит следующим образом:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# Устанавливает IP адрес (DNS сервер назначит на него доменное имя edge.openldap.local)
set interfaces ethernet eth1 address '192.168.122.100/24'
# Устанавливает IP адреса шлюза и DNS сервера
set system gateway-address '192.168.122.1'
set system dns name-server '192.168.122.250'
## Настройки подключения к LDAP серверу
# Доменное имя и порт LDAP сервера
set system ldap-server host 'ldap.openldap.local'
set system ldap-server port '389'
# Обязательный каталог, в котором производится поиск 
set system ldap-server basedn 'ou=People,dc=openldap,dc=local'
# Каталог, в котором производится поиск  пользователей
set system ldap-server userbasedn 'ou=People,dc=openldap,dc=local'
# Каталог для поиска netgroup
set system ldap-server netgroupbasedn 'ou=netgroup,ou=Groups,dc=openldap,dc=local'
# Включение поддержки StartTLS и указание клиентского сертификата
set system ldap-server tls 'enable'
set system ldap-server x509-cert 'edge'
# Включает аутентификацию через LDAP сервер
set system login ldap enabled true

Проверка аутентификации на Numa Edge:

1
2
3
4
edge01 login: john
Password: 
Creating directory '/home/john'.
john@edge01:~$