Модуль 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 интерпретирует эту строку как пустую (Корневой DN Справочника).

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

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

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

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

Пример:

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

Базовый DN:		o=myCompany
RDN Атрибут Домена:		cn

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

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

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

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

Указанная строка привязки 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 запись Справочника
	пароль Пользователя
mail=	пароль Пользователя
uid=user,cn=domain.dom,o=myCompany (Управление Пользователями через LDAP включено)	пароль Пользователя

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

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

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

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

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

Модуль 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.