Сервер LDAP состоит из двух серверных процессов slapd и slurpd. Процесс slapd занимается приёмом и обработкой запросов от клиентов; это основной процесс, который непосредственно работает с базой данных. Сервис slurpd используется в тех случаях, когда данные нужно реплицировать на другие сервера — он контролирует изменения в базе и при необходимости пересылает их на подчинённые сервера.

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

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/nis.schema
      

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

database ldbm
      

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

suffix "dc=example,dc=com"
      

Корнем информационной структуры будет являться объект dc=example,dc=com. В принципе, суффикс для каталога можно взять любой, например, o=Example Inc.,c=RU — это не накладывает абсолютно никаких ограничений на функциональность. Однако последнее время все чаще используется именно первый вид суффикса, который подчёркивает, что информационная структура данного предприятия тесно связана со структурой его домена.

rootdn "cn=admin,dc=altlinux,dc=ru"
rootpw secret
      

DN, описывающий администратора и его пароль. В данном случае пароль записан в открытом виде, поэтому файл конфигурации сервера должен иметь соответствующие права доступа, ограничивающие его чтение обычными пользователями. Пароль можно записать и в виде хэша DES или MD5 — тогда строка будет иметь следующий вид:

rootpw {MD5}IFJFxyGN3Hap7xsJFBmeTA==
index objectClass eq
      

Формат ldbm поддерживает простейшие индексы с целью ускорения операций поиска. Желательно создать такие индексы по тем атрибутам, по которым предполагается наибольшее количество запросов.

access to attr=userPassword
  by self write
  by anonymous auth
  by * none

access to * by * read
      

Не всегда данные каталога находятся в публичном доступе. Для управления доступам могут использоваться списки доступа (access lists). В данном примере приводятся два списка — в первом из них ограничивается доступ к атрибуту userPassword (полный доступ к нему могут иметь только сам объект либо администратор базы; для всех остальных доступ запрещён). Второе правило гласит, что всем даётся доступ на чтение любых данных (кроме ограниченного предыдущим правилом).

TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCertificateFile /etc/openldap/ssl/slapd.pem
TLSCertificateKeyFile /etc/openldap/ssl/slapd.pem
      

LDAP можно использовать для централизованной авторизации пользователей сети вместо NIS+. В таких случаях из каталога может запрашиваться конфиденциальная информация, например, пароль. Для предотвращения перехвата этих данных желательно использовать протокол LDAPS (LDAP via SSL/TLS).

После настройки можно сразу запустить процесс slapd — например, такой командой:

slapd -u ldap -h ldap://127.0.0.1/ ldaps://ldap.altlinux.ru/

или, если вы используете пакет из дистрибутивов ALT Linux

service ldap start

Первый объект, которые нужно создать в базе — это корневой элемент (root entry) который указан в конфигурационном файле как suffix.

Одной из важных особенностей LDAP являются встроенные средства репликации данных. Этот механизм реализован в виде отдельного серверного процесса, контролирующего изменения в базе данных и пересылающего эти изменения на другие сервера. Прежде чем включать такую репликацию, необходимо убедиться, что соответствующие данные на обоих серверах идентичны. Это связано с тем, что slurpd пересылает именно изменения на текущем сервере — он не проверяет и не анализирует состояние данных на удалённом сервере. Настройки slurpd находятся в том же файле, что и настройки slapd — поэтому перечислим, что нужно добавить к перечисленным выше параметрам:

replica /var/log/slapd.replog
      

Прежде всего укажем файл, в который slapd будет записывать все свои действия и из которого slurpd будет их читать.

replica host=ldap2.example.com
  tls=yes
  bindmethod=simple
  binddn="cn=slurpd,ou=lug,dc=example,dc=com"
  credentials=secret
      

Для каждого подчинённого сервера описывается такая вот реплика. На подчинённом сервере нужно создать соответствующий объект и указать, что он имеет права на изменение информации. Это делается с помощью соответствующего списка доступа и параметров updatedn и updateref.

Существует огромное количество клиентов, работающих с LDAP. Это могут быть почтовые программы, которые обращаются к каталогу в поисках адреса электронной почты сотрудника или за информацией о маршрутизации почты, FTP-сервер, который берет информацию для авторизации своего клиента и многие другие программы — однако все они имеют схожие настройки. Прежде всего это адрес сервера и порт, на котором работает LDAP (обычно это 389 либо 636, если сервер поддерживает протокол LDAPS). Вторым важным параметром является база поиска (Base DN) — в большинстве случаев этот параметр соответствует суффиксу сервера. Третий важный параметр — фильтр поиска. Кроме того, существуют параметры, позволяющие ограничить поиск снизу — например, только самой базой или базой и её под-объектами первого уровня, параметры управляющие поиском в алиасах (alias) и т.п.

Трёх этих параметров в большинстве случаев достаточно, чтобы выполнить запрос к любому серверу LDAP. Однако если на сервере существуют ограничения на доступ к данным, то может потребоваться авторизация. Авторизоваться в LDAP можно, указав DN одного из объектов базы данных LDAP; пароль для такого объекта будет искаться в его атрибуте userPassword.

Ниже приводится фрагмент настройки почтового сервера Postfix:

virtual_maps = ldap:virtual, hash:/etc/postfix/virtual

virtual_server_host = localhost
virtual_search_base = ou=People,dc=example,dc=ru
virtual_query_filter = (&(objectclass=inetLocalMailRecipient)(cn=%s))
virtual_result_attribute = mailLocalAddress,mailRoutingAddress
      

В данном фрагменте описывается, что при определении адреса получателя делается запрос в LDAP с целью найти объект которому это письмо адресовано. Поиск делается по атрибуту cn. Результат берётся из атрибутов mailLocalAddress и mailRoutingAddress. Эти классы и атрибуты описаны схемой misc.

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

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema

pidfile        /var/run/slapd.pid
argsfile       /var/run/slapd.args

directory      /var/lib/ldap/base
database       ldbm
index          objectClass,uid,uidNumber,gidNumber eq
index          cn,name,surName,givenName eq,subinitial
password-hash  {MD5}

suffix         "dc=example,dc=com"
rootdn         "cn=admin,dc=example,dc=com"
rootpw         {md5}$1$ION4SIII$EYyGEeYt4g2hEe9tjICac.

access to attr=userPassword
  by self write
  by dn=".*,ou=Admins,dc=example,dc=com"
  by anonymous auth
  by * none
access to * by * read

loglevel 512

index objectClass,uid,uidNumber,gidNumber     eq
index cn,mail,surname,givenname               eq,subinitial
      

После этого создадим пользователя ldap, от имени которого будет работать наш сервер и запустим процесс slapd следующей командой:

slapd -u ldap -h 'ldap://127.0.0.1/ ldap//ldap.altlinux.ru/ ldaps://ldap.altlinux.ru'

Теперь можно создать базу данных — например, с помощью утилиты ldapadd:

ldapadd -xWD cn=admin,dc=altlinux,dc=ru -H ldaps://ldap.altlinux.ru -f initial.ldif

Содержимое файла initial.ldif будет такое:

dn: dc=example,dc=com
objectClass: top
objectClass: organization
o: Exapmle Inc.
o: exapmle.com

dn: cn=admin,dc=exapmle,dc=com
objectClass: top
objectClass: organizationalRole
cn: admin
description: Example Inc. LDAP manager

dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: People
description: Stuff area

dn: uid=obender,ou=People,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: Ostap Bender
sn: Bender
givenName: Ostap
uid: obender
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/obender
loginShell: /bin/bash
userPassword: {md5}$1$ION4SIII$EYyGEeYt4g2hEe9tjICac.
mail: obender@example.com
mail: obender@attiresandtoes.com

....

dn: ou=Group,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Group
description: Groups of users

dn: cn=luser,ou=Group,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: luser
gidNumber: 1000
description: Default group for users presented by LDAP
      

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

$ ldapsearch -xLLL "(uid=obender)"
dn: uid=obender,ou=People,dc=example,dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: Ostap Bender
sn: Bender
givenName: Ostap
uid: migor
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/obender
loginShell: /bin/bash
mail: obender@example.com
mail: obender@attiresandtoes.com
      

Поскольку, согласно нашим настройкам, доступ к атрибуту userPassword имеют только сам пользователь и администратор, то этот атрибут мы не получили. Собственно, он нам и не нужен.

obender@example.com obender@attiresandtoes.com
	

virtual_maps = hash:/etc/postfix/virtual
	

$ ldapmodify -WD cn=admin,dc=example,dc=com
dn: uid=obender,ou=People,dc=example,dc=com
changetype: modify
objectClass: inetLocalMailRecipient
mailRoutingAddress: obender@attiresandtoes.com
	

virtual_maps = ldap:virtual
virtual_server_host = ldap.example.com
virtual_search_base = ou=People,dc=example,dc=com
virtual_query_filter = (&(mail=%s)(objectClass=inetLocalMailRecipient))
virtual_result_attribute = mailRoutingAddress
	

uri ldaps://ldap.example.com
ldap_version 3
base dc=example,dc=com
timelimit 15
ssl on
	

passwd: files ldap
shadow: tcb ldap
group: files ldap
	

$ id obender
uid=1000(obender) gid=1000 groups=1000