# cat /etc/sysconfig/openldap | grep LDAPI

OPENLDAP_START_LDAPI="yes"

А в других дистрибутивах надо просто настроить ключи запуска LDAP.

Вся информация внутри LDAP размещается согласно определенным схемам. Есть такая схема и для размещения информации Kerberos. Эта схема не входит в состав дистрибутивных пакетов. Но ее нетрудно разыскать в Интернете. Авторство этой схемы принадлежит PADL Software Pty Ltd. Можно взять версию, прилагаемую к статье [3], или поискать поновее по ссылке [4]. Эту схему надо положить ко всем остальным схемам и добавить соответствующую ссылку на нее в файл настроек LDAP :

# cat /etc/openldap/slapd.conf | grep krb5

include         /etc/openldap/schema/krb5-kdc.schema

Разрешим полный доступ через локальный сокет, добавив соответствующие строки в настройки ограничений доступа LDAP. Здесь используется специальный подключаемый файл slapd.access.conf , содержащий очень грубую настройку условий доступа. Можно даже сказать так, что эта настройка носит только учебный характер.

# cat /etc/openldap/slapd.access.conf | grep -v "^(#|$)"

access  to dn=".*,dc=office,dc=localnet"

        by sockurl="^ldapi:///$"                write

        by self                                 write

        by *                                    read

Согласно указанным правилам все пользователи могут читать всю базу LDAP, а вот править могут только лишь собственные контейнеры. Строка «by sockurl=”^ldapi:///$”» выбирает из всех запросов те, что поступают в LDAP через локальный сокет, и дает таким клиентским подключениям права на запись, то есть самые высокие по шкале эскалации прав LDAP. Как уже стало понятно, базовый контейнер LDAP имеет имя dc=office,dc=localnet.

Заметим, что хотя все атрибуты, использованные для хранения ключей принципалов, шифруются по мастер-ключу конкретного KDC (Kerberos Key Distribution Ceter или в русской аналогии ЦРК – центр распределения ключей), для предотвращения доступа к таким записям со стороны иных служб рекомендуется настроить соответствующим образом правила доступа к LDAP базе. Да и права, собственно, Kerberos тоже можно ограничить определенным уровнем дерева LDAP.

Но разрешить все со стороны локального сокета не достаточно. Поскольку Kerberos никак себя не аутентифицирует при подключении к LDAP, то в сеансе связи он будет считаться анонимным пользователем. В версиях OpenLDAP с индексом более 2 модификация базы через такое подключение приводит к ошибке.

Например, попытка инициализации области Kerberos завершается сообщением:

kadmin: kadm5_create_principal: ldap_add_s:

Strong(er) authentication required

Добавим специальную опцию «allow update_anon» в управляющий файл LDAP перед директивами, описывающими базу данных. Эта опция допускает изменение базы LDAP анонимным клиентом, если последнее разрешено операторами access.

Теперь можно запустить LDAP.

# rcldap start

Starting ldap-server                                                  done

server:~ # netstat -apn | grep slapd

tcp      0   0 127.0.0.1:389   0.0.0.0:*      LISTEN      11036/slapd

unix  2  [ ACC ] STREAM   LISTENING 82235 11036/slapd     /var/run/slapd/ldapi

unix  2  [ ]     DGRAM                          182233 11036/slapd