Openldap linux ��� ���

2. Установка OpenLDAP

2.1 Установка пакетов

Где работаем: ldap-srv

Прежде чем установить пакет sudo-ldap необходимо задать пароль для учетной записи root. Пакеты sudo и sudo-ldap взаимоисключающие, поэтому нужно перестраховаться, если с их установкой или работой случится беда.

Теперь установим все необходимые пакеты. Мы сразу устанавливаем krb5-kdc-ldap и sudo-ldap, даже несмотря на то, что настроим их позже. Идея заключается в том, чтобы сразу получить необходимые схемы наборов данных OpenLDAP.

Во время установки Вам будет предложено задать некоторые настройки:

• Пароль учётной записи admin для доступа к конфигурации OpenLDAP;
• Название области Kerberos (realm);
• Сервер Kerberos для нашей области;
• Управляющий сервер области.

На данном этапе эти настройки не важны. Мы последовательно опишем их в дальнейшем.

Прежде чем продолжить, убедитесь, что нужные пакеты установились:

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

Где работаем: ldap-srv

Инициализацию конфигурации каталога мы произведём с нуля с использованием нового подхода, OLC ( cn=config ).

Создайте каталог для работы со службой каталогов. У нас будет много конфигурационных файлов, неплохо бы класть их в одно место:

Избавимся от установленных по-умолчанию конфигурации slapd и его базы данных:

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

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

В этом файле первым делом мы определяем корневую запись DIT (Directory Information Tree), cn=config . С помощью директив olcPidFile и olcArgsFile мы указали, куда необходимо записать ID процесса службы каталогов и аргументы его запуска соответственно.

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

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

Модификатор -n 0 говорит о том, что мы добавляем данные в базу данных с индексом 0, который зарезервирован для cn=config .

Проверим, всё ли в порядке с нашей конфигурацией:

Поправим права доступа, разрешив пользователю openldap заправлять в каталоге /etc/ldap/slapd.d:

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

Где работаем: ldap-srv

Разрешим нашей службе каталогов использовать только IPv4. Для этого установим SLAPD_OPTIONS=»-4″ в файле /etc/default/slapd. В остальном конфигурация стандартная:

Настроим rsyslog, чтобы он писал события службы каталогов в отдельный файл. Для этого достаточно добавить три строки в его конфигурацию после глобальных директив (/etc/rsyslog.conf):

Создадим файл для журнала службы каталогов и зададим для него права доступа. Затем перезапустим rsyslog, чтобы изменения вступили в силу:

Настроим logrotate для управления этим журналом. Создадим файл конфигурации /etc/logrotate.d/slapd и запишем в него:

Проверим настройку logrotate:

Наконец запускаем нашу службу каталогов:

Заглянем в файл журнала slapd.log. Всё ли в порядке?

Проверим, активен ли TCP порт 389:

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

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

Заметьте, что slapadd (из предыдущего пункта) добавил в наш каталог описание служебной базы данных frontend (в ней можно определить опции, которые будут применяться ко всем базам данных в текущей конфигурации OLC). Однако, если те же самые опции (в том числе правила ACL) определены в конкретной базе данных, то будут применяться именно они.

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

Где работаем: ldap-srv

Для работы нам понадобится два модуля. Один — для механизма базы данных mdb. На данный момент он рассматривается как основной для нормальных баз данных и должен прийти на смену bdb и hdb. Второй модуль — monitor, для создания и динамической поддержки ветки с информацией о текущем статусе демона slapd.

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

Каталог с модулями в нашем случае — /usr/lib/ldap.

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

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

Где работаем: ldap-srv

Прежде чем добавлять наборы схем данных в каталог, необходимо подготовить наборы схем из пакетов krb5-kdc-ldap и sudo-ldap к загрузке (перевести их в формат LDIF).

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

Скопируем их во временный каталог:

На просторах сети был найден несложный скрипт для преобразования файлов schema в формат LDIF. Немного откорректируем его (для универсальности) и сохраним в том же каталоге

/ldap под именем 2.5-schema-ldif.sh:

Сделаем его исполняемым и запустим, передав через переменную SCHEMAS имена файлов конвертируемых наборов схем:

На выходе должны получить два набора схем данных в формате LDIF:

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

Удалим не нужные больше наборы схем данных:

Создадим LDIF-файл с необходимыми нам наборами схем данных. Порядок их следования в файле очень важен! Атрибуты наборов схем иерархически связаны и требуют их объявления с соблюдением иерархии. Назовём файл 2.5-add-schemas.ldif и запишем в него:

Последними строчками мы указали получившиеся в результате конвертации наборы схем kerberos.ldif и sudo.ldif.

Добавим наши наборы схем:

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

Где работаем: ldap-srv

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

Для начала создадим пароль администратора. Утилита slappasswd генерирует посоленный хэш вводимого нами пароля:

Не забудьте сам пароль! 🙂

Сформируем конфигурационный LDIF-файл для нашей базы данных (2.6-db.ldif) и запишем получившийся хэш в атрибут olcRootPW :

И вновь несколько комментариев.

• В качестве механизма манипуляции данными выбираем ранее подключенный модуль mdb.
• В качестве суффикса (корневой записи) создаваемого DIT (Directory Information Tree) обычно используется имя домена DNS. Но это не является обязательным. Для примера мы задали суффикс dc=example,dc=com .
• В атрибуте olcDbDirectory мы указали путь к каталогу бузы данных. Атрибут обязательный и требует существование каталога на момент загрузки в базу данных.
• Механизм mdb требует указания максимального размера базы данных. Он задается в байтах и должен быть больше её ожидаемого размера, даже с учётом прироста. В файловой системе должно быть достаточно свободного места для размещения базы данных такого размера.
• В атрибут olcRootDN мы записываем DN администратора нашей базы данных.
• Для пользователя, указанного в атрибуте olcRootDN , задавать правило в ACL не нужно, он обладает полным доступом к данным в вашей базе. Поэтому постарайтесь сохранить его пароль в надежном месте (например, используя keepass или gpg).
• Добавляем три правила доступа для базы данных mdb:
  • Доступ ко всей базе данных:
    • Разрешить доступ пользователю root с использованием механизма SASL EXTERNAL.
    • Продолжить анализ ACL, если нет совпадений с субъектами доступа, указанными с помощью директивы by .
  • Доступ к атрибуту userPassword :
    • Разрешить доступ для смены пароля самим пользователем.
    • Разрешить доступ для аутентификации.
  • Доступ к остальной базе данных:
    • Разрешить пользователям просматривать свои записи (важно для аутентификации через nslcd, раздел 5).
• С помощью механизма monitor включаем мониторинг базы данных (добавляем базу данных monitor ).

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

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

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

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

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

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

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

Отлично! Теперь у нас есть работающий сервер OpenLDAP.

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

С настройкой TLS мы разберемся в следующем разделе.

И последний штрих. Добавим демон нашей службы каталогов в автозагрузку:

Источник

OpenLDAP

OpenLDAP is an open-source implementation of the LDAP protocol. An LDAP server basically is a non-relational database which is optimised for accessing, but not writing, data. It is mainly used as an address book (for e.g. email clients) or authentication backend to various services (such as Samba, where it is used to emulate a domain controller, or Linux system authentication, where it replaces /etc/passwd ) and basically holds the user data.

This page is a starting point for a basic OpenLDAP installation and a sanity check.

Contents

Installation

OpenLDAP contains both a LDAP server and client. Install it with the package openldap .

Configuration

The server

Slapd, the server, stores its configuration directly inside its database. Thus, we need to write our configuration as an LDIF file and import it.

First, create a file config.ldif containing the following minimal sane configuration. This file declares the basic configuration structure and a database stored at /var/lib/openldap/openldap-data .

There are a few options you will need to change:

• Every occurence of $BASEDN must be replaced with a valid DN. If you own a domain example.com you will most likely want to choose dc=example,dc=com .
• $PASSWD must be replaced by a salted and hashed password, which you may generate by running slappasswd .

Additionally, you might consider to add further schemas and create additional indexes to tune the performance of your database. The specifics will depend on your use case, but here are a few recommendations. For LDAP authentication, you should include the three schemas below to be able to use the posixAccount object class used for storing users.

To import these settings as the ldap user using sudo:

Alternatively, you may also run this directly as root . However, if you do, make sure /etc/openldap/slapd.d/ is accessible by ldap :

By default, OpenLDAP will listen unencrypted on all interfaces. To make it only listen on local IP interfaces, you may edit the service file:

Finally, start the slapd daemon by starting slapd.service .

The client

The client configuration file is located at /etc/openldap/ldap.conf .

It is quite simple: you will only have to alter BASE to reflect the suffix of the server, and URI to reflect the address of the server, like:

If you decide to use SSL:

• The protocol (ldap or ldaps) in the URI entry has to conform with the slapd configuration
• If you decide to use self-signed certificates, add a TLS_REQCERT allow line to ldap.conf
• If you use a signed certificate from a CA, add the line TLS_CACERTDIR /usr/share/ca-certificates/trust-source in ldap.conf .

Create initial entry

Once your client is configured, you probably want to create the root entry, and an entry for the Manager role:

The text after the first line is entered on stdin, or could be read from a file either with the -f option or a file redirect.

Test your new OpenLDAP installation

This is easy, just run the command below:

Or authenticating as the rootdn (replacing -x by -D user -W ), using the example configuration we had above:

Now you should see some information about your database.

OpenLDAP over TLS

If you access the OpenLDAP server over the network and especially if you have sensitive data stored on the server you run the risk of someone sniffing your data which is sent clear-text. The next part will guide you on how to setup an SSL connection between the LDAP server and the client so the data will be sent encrypted.

In order to use TLS, you must have a certificate. For testing purposes, a self-signed certificate will suffice. To learn more about certificates, see OpenSSL.

Create a self-signed certificate

To create a self-signed certificate, type the following:

You will be prompted for information about your LDAP server. Much of the information can be left blank. The most important information is the common name. This must be set to the DNS name of your LDAP server. If your LDAP server’s IP address resolves to example.org but its server certificate shows a CN of bad.example.org, LDAP clients will reject the certificate and will be unable to negotiate TLS connections (apparently the results are wholly unpredictable).

Now that the certificate files have been created copy them to /etc/openldap/ssl/ (create this directory if it does not exist) and secure them. slapdcert.pem must be world readable because it contains the public key. slapdkey.pem on the other hand should only be readable for the ldap user for security reasons:

Configure slapd for SSL

Edit the configuration to tell LDAP where the certificate files reside by executing the following command:

If you are using a signed SSL Certificate from a certification authority such as Let’s Encrypt, you will also need to specify the path to the root certificates database and your intermediary certificate. You will also need to change ownership of the .pem files and intermediary directories to make them readable to the user ldap :

Disable SSLv2/v3 and use strong ciphers.

The TLSCipherSuite specifies a list of OpenSSL ciphers from which slapd will choose when negotiating TLS connections, in decreasing order of preference. In addition to those specific ciphers, you can use any of the wildcards supported by OpenSSL. Note: DEFAULT is a wildcard. See ciphers(1ssl) for description of ciphers, wildcards and options supported.

Start slapd with SSL

You will have to edit slapd.service to change the protocol slapd listens on.

Create the override unit:

Localhost connections do not need to use SSL. So, if you want to access the server locally you should change the ExecStart line to:

Then restart slapd.service . If it was enabled before, reenable it now.

Next steps

You now have a basic LDAP installation. The next step is to design your directory. The design is heavily dependent on what you are using it for. If you are new to LDAP, consider starting with a directory design recommended by the specific client services that will use the directory (PAM, Postfix, etc).

A directory for system authentication is the LDAP authentication article.

A nice web frontend is phpLDAPadmin.

Backup LDAP

It is imperative that we have a backup of our LDAP database and configuration in case we ever need to restore for any number of reasons.

Export configuration

Export database

Troubleshooting

slapd configuration checking

You can check configuration settings with

Client authentication checking

If you cannot connect to your server for non-secure authentication:

and for TLS secured authentication with:

LDAP server stops suddenly

If you notice that slapd seems to start but then stops, try running:

to allow slapd write access to its data directory as the user «ldap».

LDAP server does not start

Try starting the server from the command line with debugging output enabled:

Источник