# содержать логические выражения | и & которые должны стоять не между двумя скобками, а ПЕРЕД ними.

# Приведу несколько примеров фильтров: (|(cn=admin)(uid=root))  – или cn admin или UID root (cn=admin) -

# только cn = admin. В данном примере допустимым являются только объекты, принадлежащие basedn

# O=myorg, OU=sysopka

AuthLDAPUrl ldaps://test.ru/O=myorg, OU=sysopka

# Требуем только пользователей, прошедших проверку на ldap-сервере

require valid-user

</Directory>

Существует ещё несколько опций модуля, но они используются реже, и о них можно почитать в документации. Proftpd имеет схожий модуль auth-ldap, но здесь описывать его я не буду, т.к. настройка модуля ftp-сервера очень похожа на конфигурацию апача.

Настройка почтовых серверов также не представляет особой проблемы. Я, например, без проблем настроил postfix и курьер, последний настраивать особенно легко, т.к. он работает сразу же после того, как указывается LDAP-сервер, основной dn, запись администратора и её пароль в открытом виде для доступа к полям паролей пользователей (опять же можно использовать proxy). Конфигурация postfix несколько сложнее:

main.cf

virtual_maps = ldap:ldapvirtual

# Сервер ldap и порт

ldapvirtual_server_host = test.ru

ldapvirtual_server_port = 389

# Основной dn для поиска по базе

ldapvirtual_search_base = ou=mail, o=YourOrg, c=nl                

# Домен для поиска

ldapvirtual_domain = test.ru  

# Атрибут, который должен читать postfix при работе с ldap (по e-mail адресу определяется путь).

ldapvirtual_result_attribute = maildrop                                    

# Считываем одну запись из выборки                                             

ldapvirtual_scope = one

# Основной контекст и пароль

ldapvirtual_bind_dn = cn=proxy, dc=test, dc=ru

ldapvirtual_bind_pw = secret

Реплики

Ну вот, с интеграцией LDAP разобрались... Пора рассказать о дополнительных возможностях данной системы. Итак, реплики. Реплики – это одна из мощных возможностей системы директорий LDAP. Реплики – это раскопирование базы данных LDAP по нескольким серверам, т.е. фактически само дерево «размазывается» по серверам. Реплика существует между несколькими серверами, один из которых является primary (это похоже на службу DNS, только немного для других целей). В таком случае первичный сервер обрабатывает запросы на запись и на чтение, а вторичные – только на чтение. При модификации данных на главном сервере он заходит на все вторичные и синхронизирует их базы со своей. Для создания реплик необходимо три вещи: