Модуль LDAP

Модуль LDAP CommuniGate Pro обеспечивает доступ к дереву Справочника CommuniGate Pro и к его записям.

Важно понимать, что модуль LDAP CommuniGate Pro сам по себе не обеспечивает никаких услуг Справочника. В нём всего лишь реализован протокол доступа, и обеспечиваемая им функциональность зависит от Менеджера Справочника и его томов.

Очень часто услуги LDAP используются для поиска имён и адресов электронной почты пользователей Сервера. Но так как модуль LDAP обеспечивает доступ к полному дереву Справочника, то он может использоваться для работы с любыми данными, находящимися в Справочнике CommuniGate Pro. Хотя Справочник CommuniGate Pro может состоять из нескольких томов - как локальных, так и удалённых, LDAP клиенты будут видеть весь Справочник как одно большое дерево.

Для просмотра и изменения Справочника, администраторы системы могут использовать либо LDAP клиента или утилиты, либо интерфейс Просмотра Справочника, встроенный в Веб Интерфейс Администратора CommuniGate Pro.

Обратите внимание: в модуле LDAP реализована функциональность LDAP сервера; Сервер CommuniGate Pro может также работать как LDAP клиент, используя LDAP протокол для доступа к внешним LDAP серверам и их базам данных. Эти Внешние Справочники отображаются как поддерево в дереве Справочника CommuniGate Pro. Дополнительную информацию смотрите в разделе Удалённые Тома.

Для того, чтобы настроить параметры модуля LDAP, используйте Веб Интерфейс Администратора. Откройте страницу Услуги в области Установки, затем откройте страницу LDAP.

Обработка
Уровень Журнала:	КатастрофыСбоиОсновныеПроблемыПодробностиВсё	Каналы:	выкл13510255010025050010005000другое	Приёмник

Уровень Журнала

Используйте эту настройку для того, чтобы указать, какую информацию LDAP модуль должен сохранять в Журнале работы Сервера. Обычно используется уровень Основные или уровень Проблемы (не фатальные ошибки). В случае, если в работе модуля LDAP возникают проблемы, возможно целесообразным будет увеличить детализацию до уровня Подробности или Всё: в этом случае в Журнал работы Сервера будет записываться более подробная информация о работе модуля.

Записи, помещённые модулем LDAP в Журнал работы Сервера, имеют пометку LDAP. Пожалуйста, обратите внимание, что LDAP является двоичным протоколом и все низкоуровневые данные представлены в шестнадцатеричной форме.

Каналы

Когда вы указываете ненулевое значение в настройке Каналы TCP/IP, модуль LDAP создаёт так называемый "приёмник" на указанном порту. Модуль начинает принимать все LDAP соединения, которые почтовые клиенты устанавливают для того, чтобы изменить данные о пароле. Эта настройка используется для того, чтобы ограничить число одновременных соединений, которое может принимать модуль LDAP. Если открыто предельное число соединений, то модуль будет отказывать в приёме новых соединений. В этом случае пользователь должен попытаться соединиться позднее.
Если число каналов установлено равным нулю, то LDAP модуль закрывает приёмник и освобождает TCP порт(ы) ("отвязывается" от них).

Приёмник

По умолчанию, Приёмник модуля LDAP принимает незашифрованные соединения на TCP порт 389 и безопасные соединения на TCP порт 636. Нажмите на Приёмник, для того чтобы настроить порт Приёмника LDAP.

Примечание: клиенты LDAP Netscape ® до версии 4.7 заканчивали свою работу аварийно при работе с очень быстрыми серверами, возвращающими более 90 записей. Попросите ваших пользователей, использующих браузер/почтовые программы Netscape, обновиться до версии 4.7. или более поздней.

Примечание: LDAP клиент Netscape® версии 4.7. некорректно обрабатывает команду "properties" - он всегда пытается соединиться с портом номер 389, даже если предыдущий поиск был успешно выполнен через другой (например, безопасный) порт.

Иногда вам необходимо указать Корневой элемент Дерева (пустую строку) как "базу поиска DN". Некоторые LDAP клиенты не обрабатывают такую ситуацию корректно (например, LDAP клиенты Microsoft без какого бы то ни было уведомления заменяют пустую строку Базы Поиска на строку c=your_country).
В этих случаях вы должны указывать строку  top  как строку Базы Поиска. Модуль LDAP интерпретирует эту строку как пустую (Directory Root DN).

Право Доступа к Справочнику основывается на так называемом Bind DN, отличающимся от имени Пользователя CommuniGate Pro и прав Пользователя. Дополнительную информацию смотрите в разделе Права Доступа Менеджера Справочника.

Права Доступа к Справочнику, устанавливаемые по умолчанию, не требуют от клиентов Справочника (LDAP) проведения аутентификации для того, чтобы получить любую информацию из дерева Справочника.

Когда LDAP клиент пытается аутентифицироваться как какой-нибудь DN, LDAP сервер получает запись из Справочника с указанным DN и сравнивает атрибут записи userPassword с паролем, представленным клиентом LDAP. Если запись существует, в ней есть атрибут userPassword и значение атрибута соответствует представленному паролю, то аутентификация клиента LDAP считается успешной.

Модуль LDAP обеспечивает альтернативный метод аутентификации, при котором клиент указывает вместо DN какой-либо записи имя Пользователя CommuniGate Pro. В этом случае, Сервер CommuniGate Pro получает доступ к данным указанного Пользователя и сравнивает пароль Пользователя с представленным Паролем. Если пароль соответствует, то Сервер строит DN для записи Пользователя, используя настройки Центрального Справочника, и использует его как Bind DN.

Пример:

Если настройки Центрального Справочника следующие:

Base DN:		o=myCompany
Атрибут Домена RDN:		cn

и клиент предоставил имя [email protected] и правильный пароль для пользователя [email protected], то клиент LDAP аутентифицируется со следующим Bind DN:
uid=user,cn=domain.dom,o=myCompany
и этот клиент может получать доступ к информации Справочника, доступной для этого Bind DN.

Модуль LDAP использует метод альтернативной аутентификации если указанная строка не содержит символа равно (=) или если она начинается с символов mail= и не содержит других символов равно (=).

Эта услуга аутентификации может быть выключена путём выключения Услуги LDAP для домена и/или для Пользователя.

Опция Управление Пользователями через LDAP может изменять процесс аутентификации. Если эта опция включена и представленный Bind DN представляет DN для некоторого Пользователя CommuniGate Pro, то этот Bind DN преобразовывается в Имя Пользователя используется альтернативный метод.

Указанная строка Bind DN	Данные, используемые для проверки пароля
uid=user,cn=domain.dom,o=myCompany (Управление Пользователями через LDAP выключено)	атрибут userPassword записи, относящейся к записи Справочника uid=user,cn=domain.dom,o=myCompany
ou=human_resources,o=myCompany	атрибут userPassword записи, относящийся к записи Справочника ou=human_resources,o=myCompany
[email protected]	пароль Пользователя [email protected]
[email protected]	пароль Пользователя [email protected]
uid=user,cn=domain.dom,o=myCompany (Управление Пользователями через LDAP включено)	пароль Пользователя [email protected]

Модуль LDAP позволяет пользователям использовать все Методы Аутентификации, поддерживаемые Сервером CommuniGate Pro. Он поддерживает простой, безопасной (SASL) и привязанный к NTLM методы.

Если используется метод аутентификации "пароль Пользователя" и указанный Пользователь имеет права доступа Администратора Справочника, то LDAP клиент может получать доступ и изменять все данные в Справочнике (тип доступа "может всё").

Услуги LDAP могут использоваться для получения информации о Пользователях CommuniGate Pro и других Объектах Домена.

Для поиска в Справочнике Объектов Домена CommuniGate Pro (Пользователей, Групп, Списков Рассылки) клиенты LDAP должны быть настроены на использование правильного поддерева (во многих LDAP клиентах этот параметр называется "База Поиска"). Поддеревом Справочника для домена company.com является cn=company.com,o=MyCompany, где cn - это RDN Атрибут Домена, а o=MyCompany - это Base DN для Доменов CommuniGate Pro. Base DN и RDN Атрибут Домена являются настройками Центрального Справочника, которые могут быть изменены. При изменении этих настроек местоположение поддерева доменов изменяется и настройки "База Поиска" LDAP клиентов должны быть изменены таким образом, чтобы они также использовали новое местоположение.

Некоторые внешние приложения и устройства (такие как внешние E-mail фильтры) используют протокол LDAP для проверки, может ли почта быть принята на указанный адрес.
Такие приложения проверяют существование адреса E-mail object@domain, используя один из следующих запросов:

• запрос "чтения записи" (scope=base) на DN вида mail=object@domain, searchbase или
• запрос "поиска записи" (scope=one) на DN searchbase c фильтром mail=object@domain

Для поддержки таких приложений и устройств, модуль LDAP сервера CommuniGate Pro реализует виртуальное поддерево справочника: dc=cgprouter. Если запрос "чтения записи" (scope=base) сделан на DN mail=object@domain,dc=cgprouter, или запрос "поиска записи" (scope=one) сделан на DN dc=cgprouter со строкой фильтра mail=object@domain, то Модуль LDAP не обращается к Справочнику. Вместо этого он обрабатывает указанный адрес object@domain с помощью компоненты Маршрутизатор.

Если указанный адрес E-mail успешно маршрутизируется в Пользователя системы или в "Чёрную дыру" или результат маршрутизации указывает на внешний хост, на который разрешена передача почты, то Модуль LDAP возвращает в результате фиктивную запись, указывая тем самым приложению, что был указан правильный адрес E-mail, и что почта на этот адрес может быть принята.

Если адрес не маршрутизируется (или релеинг на него не разрешён), результат для запроса "поиска записи" будет пустым. Результат запроса "чтения записи" в таком случае содержит ошибку маршрутизации.

CommuniGate Pro поддерживает Домены в Справочнике. Информация о Пользователе в таких доменах хранится в Справочнике и для изменения данных Пользователя в Справочнике может использоваться модуль LDAP. Домены в Справочнике напоминают по своей архитектуре некоторые старые почтовые системы и CommuniGate Pro поддерживает их по соображениям совместимости и упрощения процесса миграции. Дополнительную информацию смотрите в разделе Домены в Справочнике.

Модуль LDAP будет также может использоваться для выполнения базовых операций управления пользователями в обычных Доменах. Эта возможность называется Управление Пользователями через LDAP. Если DN, указанный в запросе, "выглядит как" DN записи в Справочнике, которую имеет (или может иметь) какой-нибудь Пользователь CommuniGate Pro, то модуль LDAP не будет выполнять никаких операций в Справочнике. Вместо передачи запроса в Справочник, модуль LDAP отправляет команду непосредственно Менеджеру Пользователей, и Менеджер Пользователей создаёт/удаляет/переименовывает/обновляет/читает информацию указанного Пользователя. Дополнительную информацию смотрите в разделе Центральный Справочник.

Многие из LDAP клиентов ожидают встретить атрибут mail у Пользователя и в других записях Объектов Домена. Однако, по умолчанию CommuniGate Pro не хранит этот атрибут в этих записях справочника.

Если модуль LDAP должен вернуть такую запись (запись объектов класса CommuniGateAccount, CommuniGateMailList или CommuniGateGroup) и эта запись не содержит атрибута mail, то LDAP модуль может сформировать этот атрибут во время выполнения запроса, используя запись DN Объекта: он берёт значение uid из DN (Пользователь/Имя Объекта), значение атрибута cn (имя Домена) и объединяет их, используя символ @ для того, чтобы построить значение атрибута mail uidValue@cnValue. В результате, когда объект переименовывается (изменяется его атрибут записи uid) или когда переименовывается домен (изменяется атрибут cn в DN объекта), атрибут mail также автоматически обновляется.

Так как по умолчанию атрибут mail не сохраняется в записях Справочника, то все фильтры поиска, использующие атрибут mail, вместо этого могут быть изменены на использование атрибута uid. Если операцией поиска является "равно" и строка поиска содержит символ @, то используется только часть строки поиска перед этим символом.

Эти две возможности могут быть включены или выключены через Веб Интерфейс Администратора на странице Центральный Справочник в области Пользователи:

Обработка Атрибутов для LDAP

Заменять 'mail' на 'uid' в условиях

Формировать 'mail' из 'uid'

Игнорировать условия на 'objectCategory'

Игнорировать условия на 'objectCategory'

Некоторые клиенты (включая Microsoft Outlook) всегда посылают LDAP запросы на поиск используя фильтры, проверяющие определённые значения атрибута objectCategory.
Так как по умолчанию этот атрибут не включён в записи Пользователя CommuniGate Pro, то вы должны создать этот атрибут как Дополнительный, и установить "правильное" значение для каждого Пользователя.
Эта опция указывает LDAP серверу игнорировать все операции поиска вида "objectCategory равно значение"(Сервер считает эти операции константой истина).

Модуль LDAP проверяет, не указывает ли запрос на поиск в явном виде атрибут displayName. Если полученные записи не имеют этого атрибута, но имеют атрибут cn или атрибут uid, то значение атрибута cn или uid включается в ответ как значение атрибута displayName.

Модуль LDAP поддерживает расширение Simple Paged Results Manipulation (RFC2696), которое позволяет клиентам читать с Сервера большие результаты поиска маленькими частями (страницами).
Однако, чтобы выдать клиенту одну страницу, Сервер должен произвести поиск всех записей, удовлетворяющих критериям поиска, затем (опционально) отсортировать их, и только потом он может выдать запрошенную страницу результатов. Чтобы предотвратить падение производительности, вызванное повторяющимися поисками и сортировками, Сервер может кэшировать несколько таких результатов поиска в своей внутренней памяти.

Параметры кэширования могут быть настроены через Веб Интерфейс Администратора на странице Центральный Справочник в области Пользователи:

Кэш постраничной Выдачи Результатов поиска LDAP
Размер:0123 510203050другое	Используется: 1
Тайм-аут:60 сек2 мин3 мин 4 мин5 мин10 мин20 мин30 мин60 миндругое

Размер

Максимальное число кэшируемых результатов поиска.

Используется

Число закэшированных результатов в данный момент.

Тайм-аут

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