Взгляд интегратора на отечественные почтовые системы – часть 2

Привет, Хабр! Меня зовут Илья, и в этой статье я продолжу своё повествование о российских почтовых системах, а именно расскажу об особенностях взаимодействия и интеграции почтовых систем с каталогом LDAP.

Первая часть – про архитектуру и компоненты российских почтовых систем – здесь.

Герои этой статьи всё те же:

1. RuPost Enterprise

2. Tegu Enterprise (МБК-Лаб)

3. VK WorkSpace

4. DeepMail

Примечание: порядок перечисления случайный и никак не связан с моей симпатией к тому или иному решению.

LDAP

Выражение «Театр начинается с вешалки» в контексте статьи можно заменить на «Корпоративные почтовые системы начинаются с коннектора к LDAP». Кто-то может возразить: «Нет, всё начинается с настройки DNS!» – и будет прав. Но поскольку настройки DNS в целом однотипны и не зависят от конкретной реализации почтового сервера, то позволим сделать это отступление и начнём именно с подключения к LDAP.

Помимо самого подключения к LDAP, разберём вопросы создания почтовых ящиков, их псевдонимов, настройки групп и работу с Глобальной адресной книгой (GAL, Global Address List), поскольку все эти моменты так или иначе связаны с LDAP. Также расскажем про работу почтовых систем с несколькими почтовыми доменами.

RuPost Enterprise

Подключение к LDAP

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

RuPost использует сквозную аутентификацию, не синхронизирует данные серверов каталогов, поэтому не может их скомпрометировать.

RuPost Enterprise (текущая версия на момент написания статьи – 3.1.0) поддерживает подключение следующих видов каталогов LDAP:

• Active Directory;

• ALD Pro;

• FreeIPA;

• Samba DC (RFC2307).

Можно подключить несколько каталогов LDAP разных типов одновременно.

Active Directory и ALD Pro не требуют каких-либо дополнительных действий при подключении, а для FreeIPA перед подключением нужно выполнить bash-сценарий (также предоставляется RuPost), который модифицирует схему каталога. Каталог Samba DC должен соответствовать RFC2307, в этом случае набор его атрибутов совпадает с атрибутами Active Directory и никаких дополнительных действий также не требуется.

Естественно, поддерживается подключение к LDAP-домену через SSL. Для SSL-подключения соответствующий сертификат должен быть добавлен в Trusted на всех узлах – экземплярах RuPost.

Чего нельзя, так это указать корень поиска (Base DN) каталога LDAP и фильтр поиска пользовательских учётных записей. Поэтому после того, как LDAP будет подключён, RuPost увидит его целиком. Надеюсь, в следующих релизах подобные механизмы фильтрации будут добавлены. А пока этот момент можно нивелировать правами служебной учётной записи для просмотра каталога только для конкретных CN/OU (что, конечно же, добавляет труда для её создания). Эта учётная запись, помимо просмотра всех атрибутов каталога, должна также обладать правами на запись для атрибутов mail (первичный адрес электронной почты) и proxyAddresses (псевдонимы п/я). Зачем – расскажу ниже.

Настройка периода обновления каталога не предусмотрена: по умолчанию это 6 часов, однако есть консольный командлет rupost, который позволяет принудительно синхронизировать LDAP. Для этого достаточно выполнить sudo rupost ldap sync. При обновлении каталога обновляются свойства владельца зарегистрированных п/я, на авторизацию пользователей в LDAP это не влияет.

Отмечу, что использование атрибутов для вышеперечисленных видов каталогов достаточно хорошо задокументированы вендором, при возникновении вопросов нелишним будет заглянуть в документацию.

Создание п/я

Почтовые ящики создаются вручную методом добавления из LDAP, можно создать несколько ящиков (группой) за раз. Необходимо указать, откуда берём пользователя или пользователей по шаблону (каталог LDAP) и где создаём п/я (почтовый домен).

Возможны любые комбинации каталога LDAP и почтового домена, если у вас их несколько. Можно указать группу почтовых ящиков, которая определяет пространство хранения NFS – их также может быть несколько, и групповую политику квот.

Настройка квот включает квоту на размер почтового ящика и максимальный размер входящего письма. И квот, и групп п/я может быть несколько, но только одна из них имеет статус «по умолчанию». Если при создании п/я ничего из этих параметров не выбирать – применятся настройки по умолчанию.

На следующем этапе необходимо определить стратегию заведения почтовых ящиков. Можно выполнить импорт первичных почтовых адресов из LDAP (если они там есть). Если их нет или требуется поменять существующие адреса, можно пойти по более интересному пути: сгенерировать первичные почтовые адреса по шаблону (именно для такого сценария и нужны права на запись для атрибутов LDAP mail и proxyAddresses). Шаблон может включать полные фамилию, имя и/или отчество, инициалы, логин – в любом порядке. Данные для шаблона при этом «подтягиваются» из LDAP.

В результате создадутся п/я в формате <шаблон>@<почтовый домен>.

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

Нужно заметить, что после создания п/я лезть руками в LDAP и править атрибуты mail и proxyAddresses строжайше запрещено! В противном случае почтовый ящик станет недоступным.

Списки рассылки (групповые п/я)

RuPost не использует существующие группы LDAP напрямую для автоматической генерации списков рассылки, а вместо этого предлагает два варианта их создания:

• статические списки рассылки – список получателей, в т.ч. и для внешних по отношению к RuPost почтовых доменов;

• динамические списки рассылки оперируют LDAP-запросами, с помощью которых формируют списки п/я. LDAP-запросы создаются отдельно, можно «доставать» пользователей из групп (как в примере ниже) и делать многое другое, если не сказать всё – вы ограничены только теми данными, которые есть в каталоге!

Для обоих типов рассылки можно включить опцию «Со всех адресов» — это сделает доступным рассылку с внешних адресов.  Также есть опция «Со всех внутренних адресов»: если её отключить, то появится возможность добавить список разрешённых отправителей (только из почтовых доменов RuPost). Применение списков рассылки не использует лицензии RuPost.

Глобальная адресная книга

Глобальная адресная книга RuPost автоматически формируется на основе информации о пользователях, собираемой из подключенных служб каталогов. Хранится GAL в Постгрес, БД rupost, таблица rp-gal – это на случай, если потребуется контролировать её наполнение.

Обновление адресной книги происходит периодически – раз в 6 часов, также можно принудительно обновить GAL с помощью уже упомянутого консольного командлета rupost – sudo rupost make-gal.

Есть возможность настройки, чтобы в корпоративную адресную книгу попадали только первичные адреса электронной почты пользователей (из атрибута mail, атрибут proxyAddresses исключается).

Другие механизмы управления наполнения GAL отсутствуют. И поскольку, как я уже заметил, нельзя указать корень поиска (Base DN) каталога LDAP и/или фильтр поиска пользовательских учётных записей, вследствие чего RuPost «видит» весь LDAP, в сформированный GAL попадают все записи с заполненным атрибутом mail, в т.ч. с почтовыми адресами, не совпадающими с доменами, которыми управляет RuPost. Кроме того, в GAL переносятся заблокированные пользователи.

В целом, на мой взгляд, реализация механизма создания слепка GAL в базе данных, наполнение которого можно контролировать, пусть и не штатными средствами RuPost, является хорошей идеей. Вместе с тем остаётся надеяться на добавление в будущем в RuPost функций управления наполнением GAL, включая фильтры и настройку периода синхронизации.

Подключение GAL к почтовому клиенту осуществляется по протоколу CardDAV с шифрованием, при наличии правильно настроенных записей в DNS (RuPost публикует рекомендованные записи DNS при создании почтового домена) CardDAV в десктопном почтовом клиенте настраивается автоматически. Я тестировал стандартный Thunderbird, десктопный клиент RuPost на базе Thunderbird, а также плагин RuPost для Outlook – всё работает корректно. Настройка входящего в экземпляр RuPost почтового веб-клиента SoGo для работы с GAL выполнена изначально и не требует дополнительных действий.

Tegu Enterprise

Подключение к LDAP

Служба каталогов используется для аутентификации в LDAP пользователя Tegu при любой операции работы с почтовым ящиком. Настройка подключения осуществляется для конкретного почтового домена. В рамках одного домена может быть использовано неограниченное количество источников баз пользователей в любой комбинации типов. Число обслуживаемых почтовых доменов также не ограничено.

Tegu использует сквозную аутентификацию, не синхронизирует данные серверов каталогов и не может их скомпрометировать. Учётной записи для подключения к каталогу LDAP (BindDN) требуются права на просмотр всех атрибутов каталога, права на запись в атрибуты не нужны.

В настройках подключения можно указать корень поиска (Base DN), а также управлять минимальной версией TLS для пользовательских подключений. Имеется возможность управлять временем хранения LDAP в кэше Tegu для снижения нагрузки на LDAP, а также задать фильтр поиска пользователей и групп, отсекая, например, заблокированных пользователей или пользователей с незаполненным полем mail.

Tegu не использует готовые профили типов LDAP, предоставляя богатый функционал гибкой настройки атрибутов. Можно определить атрибуты типа objectClass для пользователей и групп, атрибут членства в группах memberOf, задать атрибут для хранения e-mail, атрибуты для псевдонимов и многое другое. Такой подход делает подключение провайдера пользователей чрезвычайно гибким и позволяет подключать практически любой каталог LDAP. В документации вендора приведены примеры заполнения атрибутов для Active Directory и OpenLDAP.

После выполнения всех настроек есть возможность проверить подключение к LDAP. Впрочем, это можно выполнить на любом этапе, тестируя те или иные настройки, например, LDAP-фильтры поиска.

Квотирование размера п/я также определяется через атрибут и должно храниться в LDAP.

Создание п/я

Для создания почтового ящика в Tegu необходимо, чтобы соответствующий атрибут пользователя (mail) был заполнен почтовым адресом, совпадающим с почтовым доменом, который обслуживает система. Редактирование почтовых адресов осуществляется исключительно в каталоге LDAP.

Почтовые ящики Tegu создаются при наступлении одного из следующих событий:

• пользователь аутентифицировался в почтовой системе Tegu любым способом: через личный кабинет веб-интерфейса, десктопный или мобильный клиент, почтовый веб-клиент;

• на почтовый адрес в обслуживаемом Tegu домене пришло письмо (не важно от кого – от внешнего отправителя или внутри почтового домена).

Созданные п/я, информацию об их текущем размере, квоте, количестве писем можно посмотреть в административном интерфейсе Tegu.

Таким образом, процедуру создания п/я можно считать полностью автоматизированной (за исключением заполнения e-mail в каталоге LDAP), и, что важно, она выполняется on-demand только тогда, когда это необходимо. Это позволяет существенно снизить нагрузку на саму почтовую систему в период начала промышленной эксплуатации и оптимизировать использование лицензий.

Списки рассылки (групповые п/я)

Списки рассылки берутся из LDAP в виде пользовательских групп, для группы в LDAP также должен быть определён e-mail. Применение списков рассылки не использует лицензии Tegu.

Примечание: Tegu не обрабатывает системные группы типа Domain Users, что в общем-то разумно. Если нужно сделать список рассылки – создайте группу с пользователями и заполните соответствующий атрибут почтовым адресом.

Для того, чтобы группы корректно определялись Tegu, необходимо заполнить атрибуты, как показано ниже (конкретное наполнение зависит от типа каталога LDAP):

Глобальная адресная книга

Все источники баз пользователей используются как единая (объединенная) база для формирования глобальной адресной книги (в разрезе почтовых доменов).

Для создания и синхронизации GAL доступен внушительный арсенал настроек. В разрезе каждого провайдера (каталога LDAP) можно управлять периодом синхронизации с дискретностью до минуты и настроить отдельный LDAP-фильтр для GAL, убрав заблокированных пользователей или записи с незаполненными по шаблону атрибутами mail.

Например, так:

(|(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(&(mail=*@mailtest.local)(!(mail=\20*))))(&(objectClass=group)(mail=*@mailtest.local)))

При этом GAL содержит как пользователей, так и группы рассылок.

Кроме перечисленного, можно отключить GAL для выбранного провайдера LDAP. Для некоторых сценариев это может оказаться полезным.

Для групп, как и для пользователей, есть настройки сопоставления полей адресной книги с атрибутами LDAP.

Неполный список полей настройки GAL Tegu ниже:

GAL хранится в кэше Tegu, способов его оперативно обновить два: изменить период обновления GAL в административном интерфейсе или рестартовать сервис Tegu. Какие-либо возможности контроля содержимого GAL в кэше Tegu найдены не были. Способ только один, но он и самый надёжный – подключиться почтовым клиентом и синхронизировать глобальную адресную книгу.

Подключение GAL к почтовому клиенту осуществляется по протоколу CardDAV с шифрованием TLS. При наличии правильно настроенных записей в DNS (а Tegu в т.ч. публикует рекомендованные записи для конкретного домена) CardDAV в почтовом клиенте (я тестировал стандартный Thunderbird) настраивается автоматически, причём как GAL, так и персональные адресные книги. Также пользователь может найти персональные ссылки для подключения CardDAV на личной веб-странице Tegu.

VK WorkSpace

Подключение к LDAP

VK WorkSpace имеет два взаимоисключающих режима работы с пользователями: с локальной, вручную заполняемой базой (также возможен импорт из файла) или с каталогом LDAP.

VK WorkSpace переносит из LDAP список пользователей, группы рассылок и контакты. При этом VK WorkSpace не хранит пароли пользователей, то есть вся цепочка аутентификации происходит на стороне AD (LDAP-провайдера). Для каждого домена интеграция с LDAP настраивается отдельно.

По умолчанию работа с каталогом LDAP выключена, при её активации (самый нижний чек-бокс окна настроек) локальные пользователи становятся неактивными.

В настройках подключения нет выбора типа LDAP, однако на экране настройки везде упорно используются названия «Active Directory» и «AD». Объяснить такой подход я не могу, поскольку поддерживаются как каталоги Active Directory, так и FreeIPA и ALDPro. В документации есть отдельные параграфы для этих типов LDAP. Из настроек атрибутов присутствует только поле свойства «Отчество». Можно задать корень поиска BaseDN, он называется «Каталоги пользователей». Сертификат для шифрованного соединения можно добавить на этой же странице настроек.

За синхронизацию с LDAP отвечает контейнер Adloader, запуск и управление которым осуществляются сервисом onpremise-container-adloader*.service, где * – порядковый номер фронта (1 или 2 для стандартной кластерной установки с двумя фронтами).

Для мониторинга выполнения сервиса можно использовать команду, выполняемую на фронтах (фронт vk-f1):

sudo journalctl -fu onpremise-container-adloader1.service

Синхронизация осуществляется только для учётных записей, у которых атрибут mail содержит значение типа user@domain.ru, совпадающее с обслуживаемым доменом.

Есть возможность редактирования фильтра LDAP и сопоставления атрибутов посредством правки конфигурационного файла adloader в расширенном интерфейсе управления. В примере ниже к существующему сопоставлению атрибута «"middle_name": "initials"» были добавлены дополнительные атрибуты (с комментариями). Документации по данным настройкам нет в публичном доступе, она предоставляется вендором по запросу.

В этих же настройках Adloader можно поменять интервал синхронизации ("sync_interval": "1h"), минимальное значение – 5 минут.

Создание п/я

Почтовые ящики создаются в полностью автоматическом режиме в процессе синхронизации VK WorkSpace с каталогом LDAP. Именно поэтому процесс первоначальной синхронизации занимает много времени.

Из документации вендора:

«Если AD содержит много данных, то одного часа может быть недостаточно для синхронизации всего объема. В этом случае через час после настройки подключения в разделе «Пользователи» отобразятся не все пользователи из AD, а только часть. Просто подождите еще час».

По моему опыту, первоначальная синхронизация с Active Directory, содержащей порядка 50 тыс. объектов, и создание 10 000 п/я занимают около 4-х часов. Данные результаты получены с «настройками по умолчанию» для VK WorkSpace. Вместе с тем, у вендора есть рекомендации по тонкой настройке производительности контейнеров, в частности для уже упомянутого сервиса Adloader, выполнение которых поможет сократить время первичной синхронизации с каталогом LDAP. Данная информация предоставляется вендором по отдельному запросу.

Выполнение синхронизации можно отслеживать в интерфейсе администрирования, есть счётчик количества синхронизированных пользователей и созданных почтовых ящиков:

Списки рассылки (групповые п/я)

Списки рассылки берутся из LDAP в виде групп рассылки ("distribution groups" в терминах LDAP), для группы в LDAP также должен быть определён e-mail. Применение списков рассылки не использует лицензии VK WorkSpace.

Наряду с синхронизацией списков рассылки из LDAP можно создавать локальные списки рассылки в интерфейсе администрирования. Например, на картинке ниже группа info создана локально, а другие группы получены из AD.

Глобальная адресная книга

Работа VK WorkSpace с Active Directory в части Глобальной адресной книги не требует дополнительных настроек, после синхронизации GAL содержит всю необходимую информацию:

Не «подтянулось» только поле «Руководитель», с этим ещё предстоит разобраться