KSMG Подготовка конфигурационных файлов для подключения к LDAP
Подготовка конфигурационных файлов для подключения к LDAP
Перед тем, как настроить
верификацию получателей через LDAP на встроенном MTA, необходимо подготовить
конфигурационный файл, содержащий параметры подключения к LDAP-серверу. Если у
вас несколько доменов (лесов) Active Directory, для каждого из них необходимо
подготовить отдельный конфигурационный файл.
Каждый файл с
параметрами подключения к LDAP представляет собой обычный текстовый файл в
формате Unix (LF переводы строк). Имена файлов должны быть такими: ldap_map1.cf, ldap_map2.cf и
т.д.
Процедура подготовки
конфигурационного файла состоит из следующих шагов:
1) Создайте на
контроллере домена сервисную учетную запись со сложным паролем, которая будет
использоваться для подключения к LDAP-серверам данного домена (леса доменов).
Для примера будем использовать учетную запись с именем ksmg-relay.
2) Определите DN
(Distinguished Name) сервисной учетной записи. Это можно сделать, например, при
помощи команды dsquery на контроллере домена:
dsquery
user -Name ksmg-relay
DN сервисной учетной
записи должен иметь примерно следующий вид:
CN=ksmg-relay,OU=Service Accounts,OU=Users,DC=example,DC=com
3) Определите параметры
поиска в LDAP - базу поиска (search_base) и строку запроса (query_filter).
4) Создайте текстовый
конфигурационный файл, укажите в нем все обязательные параметры.
В таблице ниже
перечислены обязательные параметры, которые должны быть указаны в
конфигурационном файле. Более подробное описание всех доступных параметров см.
в документации Postfix - http://www.postfix.org/ldap_table.5.html
|
Параметр |
Описание параметра |
|
server_host |
Одна или несколько точек подключения к LDAP, перечисляются через запятую. Формат точки
подключения: Протокол - ldap, либо
ldaps (безопасное подключение поверх SSL, рекомендуется). Адрес - IP-адрес, либо
доменное имя (конкретного контроллера домена, или общее, для равномерного
распределения нагрузки). Порт - номер TCP-порта
для подключения. Возможные значения: Подключение к службе
глобального каталога может использоваться, если у вас несколько доменов
Active Directory, объединенных в общий лес. Пример: Безопасное
подключение по протоколу LDAPS, перечислены имена нескольких контроллеров
домена Пример: Безопасное
подключение к службе глобального каталога, указано имя конкретного
контроллера домена Пример: Небезопасное
подключение по протоколу LDAP, перечислены IP-адреса нескольких контроллеров
домена |
|
version |
Версия протокола LDAP, всегда должно быть 3. Пример: |
|
timeout |
Таймаут LDAP-запроса (в секундах). В случае истечения таймаута произойдет
переключение на следующую точку подключения. Пример: Таймаут 10
секунд (подходит, если указана одна точка подключения, или LDAP-серверы
сильно нагружены) Пример: Таймаут 5 секунд (для
более быстрого переключения в случае нескольких точек подключения) |
|
search_base |
База для поиска записей в LDAP. Примеры ниже даны для домена example.com. Пример: поиск от корня
домена |
|
query_filter |
Строка запроса для поиска записей в LDAP. Примечание: служба
глобального каталога поддерживает только атрибут mail, атрибут ProxyAddresses
не реплицируется. Пример: поиск e-mail адресов по атрибуту proxyAddresses Пример: поиск e-mail адресов по атрибуту mail Пример: поиск e-mail адресов одновременно по двум атрибутам |
|
result_attribute |
Результирующий атрибут. Для верификации получателя конкретный атрибут
значения не имеет, можно использовать cn. Пример: |
|
bind |
Использовать ли привязку учетной записи при подключении, всегда должно
быть yes. Пример: |
|
bind_dn |
DN сервисной учетной записи, используемой для подключения к LDAP. Пример: |
|
bind_pw |
Пароль сервисной учетной записи. Пример: |
Пример
конфигурационного файла для подключения к LDAP:
|
server_host =
ldaps://dc1.example.com:636, ldaps://dc2.example.com:636 version = 3 timeout = 5 search_base =
DC=example,DC=com query_filter =
(&(|(objectclass=User)(objectclass=Group))(|(proxyAddresses=smtp:%s)(mail=%s))) result_attribute
= cn bind = yes bind_dn =
CN=ksmg-relay,OU=Service Accounts,OU=Users,DC=example,DC=com bind_pw = XEZ6Lqu5KA9CTn+fY |
Дополнительно можно
создать фиксированный список почтовых адресов и/или почтовых доменов, для
которых Kaspersky Secure Mail Gateway будет пропускать электронную почту. Если
почтовый адрес либо почтовый домен получателя присутствует в этом списке,
адресат будет считаться существующим и проверка его наличия через LDAP
производиться не будет. Таким образом, этот список можно использовать для
обхода проверка через LDAP, если есть такая необходимость.
Данный список
представляет собой обычный текстовый файл в формате Unix (LF переводы строк) с
именем relay_bypass (без расширения). Формат содержимого файла
описан в таблице ниже, каждая запись в файле располагается на новой строке.
|
Формат записи |
Описание |
|
recipient@example.com OK |
Почтовый
адрес (только указанный адресат) |
|
@example.com OK |
Почтовый
домен (любой адресат с данным доменом) |
Пример содержимого
файла:
|
postmaster@example.com
OK hr@example.com
OK @company.com OK |
После того, как
конфигурационные файлы для подключения к LDAP подготовлены, можно переходить к
настройке верификации получателей через LDAP на встроенном MTA.
Настройка верификации
получателей через LDAP на встроенном MTA
Перед тем, как настроить
верификацию получателей через LDAP, необходимо отключить действующий механизм
проверки получателей. Для этого зайдите в веб-интерфейс управляющего узла,
перейдите в раздел Параметры - Встроенный MTA - Расширенные параметры, найдите
параметр Отклонять сообщения на адреса получателей, переключите его
в режим Не отклонять.
Далее, чтобы настроить
верификацию получателей на встроенном MTA через LDAP, необходимо выполнить
процедуру, описанную ниже. Эти действия необходимо повторить на каждом узле
кластера Kaspersky Secure Mail Gateway, для обеспечения консистентной работы
кластера.
1) Подключитесь к узлу
кластера по SSH, чтобы получить доступ к режиму технической поддержки.
2) Поместите
подготовленные ранее файлы конфигураций для подключения к LDAP-серверам в
директорию /etc/postfix. Конфигурационные файлы должны иметь имена
ldap_map1.cf, ldap_map2.cf и т.д.
3) Задайте владельца и
права доступа к файлам конфигурации:
cd /etc/postfix
chown root:root
ldap_map*.cf
chmod 600
ldap_map*.cf
4) Проверьте при помощи
команды postmap, что поиск получателя по e-mail через LDAP осуществляются
успешно (вместо existing.recipient@example.com укажите адрес существующего
пользователя):
postmap -q existing.recipient@example.com
ldap:/etc/postfix/ldap_map1.cf
В случае успеха, команда
выведет в консоль CN (Common Name) пользователя, которому соответствует
указанный e-mail адрес. Процедуру проверки необходимо выполнить для каждого
конфигурационного файла. В случае, если команда ничего не выведет на консоль
или выдаст ошибку, проверьте параметры, указанные в конфигурационном файле.
Дальнейшие шаги можно выполнять только в случае, если все конфигурационные
файлы успешно прошли проверку.
5) Если у вас есть
дополнительный список получателей для обхода проверки через LDAP, поместите
подготовленный файл relay_bypass в директорию /etc/postfix,
затем выполните следующие команды:
cd /etc/postfix
chown root:root
relay_bypass
chmod 640
relay_bypass
postmap relay_bypass
6) Перейдите в каталог,
где находятся шаблоны конфигурационных файлов встроенного MTA:
cd /opt/kaspersky/ksmg-appliance-addon/share/templates
7) Сделайте резервную
копию файла шаблона main.cf.template, если не делали этого ранее:
cp -p main.cf.template main.cf.template.backup
8) Откройте на
редактирование файл main.cf.template при помощи текстового редактора:
vim main.cf.template
9) Найдите строку smtpd_reject_unlisted_recipient
= no, закомментируйте ее (отмечено красным цветом) и добавьте новые строчки
ниже (отмечено зеленым цветом):
Если у вас один
конфигурационный файл для подключения к LDAP:
# smtpd_reject_unlisted_recipient = no
# Check recipients via LDAP map
smtpd_reject_unlisted_recipient = yes
relay_recipient_maps = ldap:$config_directory/ldap_map1.cf
Если у вас несколько
конфигурационных файлов, необходимо их перечислить в параметре
relay_recipient_maps через запятую:
# smtpd_reject_unlisted_recipient = no
# Check recipients via LDAP map
smtpd_reject_unlisted_recipient = yes
relay_recipient_maps = ldap:$config_directory/ldap_map1.cf,
ldap:$config_directory/ldap_map2.cf
Если у вас есть
дополнительный список адресов для обхода проверки через LDAP, добавьте его в
директиву relay_recipient_maps перед параметрами LDAP следующим образом:
relay_recipient_maps = hash:$config_directory/relay_bypass,
ldap:$config_directory/ldap_map1.cf
10) Если вы хотите
изменить код ошибки SMTP для несуществующего адреса получателя с перманентной
ошибки (код 550) на временную ошибку (код 450), добавьте следующую строку после
директивы relay_recipient_maps:
unknown_relay_recipient_reject_code = 450
11) Сохраните
изменения в файле main.cf.template.
12) Чтобы изменения в
шаблоне применились, поменяйте какую-нибудь настройку встроенного MTA через
веб-интерфейс. Например, можно увеличить на единицу значение параметра Ограничение
размера сообщения (Параметры - Встроенный MTA - Основные параметры),
сохранить изменения, а потом вернуть предыдущее значение обратно.
13) Проверьте, что
изменения попали в основной конфигурационный файл встроенного MTA:
less
/etc/postfix/main.cf
14) Проверьте статус
сервиса postfix, он должен быть running:
systemctl
status postfix
На этом процедура
завершена, механизм проверки получателей через LDAP настроен. Процедуру
необходимо повторить на каждом узле кластера Kaspersky Secure Mail Gateway.
Проверка работы механизма
верификации получателей
После того, как был
настроен механизм верификации получателей через LDAP, необходимо проверить его
работоспособность:
1) Подключитесь к узлу
кластера по SSH, чтобы получить доступ к режиму технической поддержки.
2) Отправьте письмо
через данный узел кластера по протоколу SMTP на существующий адрес. Проверьте
по файлу лога /var/log/maillog, как письмо было обработано встроенным MTA.
Ожидаемый результат -
сообщение было принято с кодом 250:
Apr 05 12:00:00 ksmg01.example.com
postfix/smtpd[34903]: proxy-accept: END-OF-MESSAGE: 250 2.0.0 OK;
from=<check@example.com> to=<existing.recipient@example.com>
proto=ESMTP helo=<mx.example.com>
3) Отправьте письмо
через данный узел кластера по протоколу SMTP на несуществующий адрес. Проверьте
по файлу лога /var/log/maillog, как письмо было обработано встроенным MTA.
Ожидаемый результат -
сообщение было отклонено с кодом 550 (либо 450, если вы меняли код ошибки):
Apr 05 12:00:00 ksmg01.example.com
postfix/smtpd[14258]: NOQUEUE: reject: RCPT from mx.example.com[10.88.44.90]:
550 5.1.1 <wrong.recipient@example.com>: Recipient address rejected: User
unknown in relay recipient table; from=<check@example.com>
to=<wrong.recipient@example.com> proto=ESMTP helo=<mx.example.com>
4) Дополнительно можно
проверить, как ведет себя MTA в случае, когда LDAP-сервер недоступен. Для этого
ограничьте доступ к LDAP-серверу со стороны данного узла кластера (например,
при помощи фаервола). Отправьте письмо через данный узел кластера по протоколу
SMTP на существующий адрес. Проверьте по файлу лога /var/log/maillog, как
письмо было обработано встроенным MTA.
Ожидаемый результат -
сообщение было отклонено с кодом 451:
Apr 05 12:00:00 ksmg01.example.com
postfix/smtpd[20451]: NOQUEUE: reject: RCPT from mx.example.com[10.88.44.90]:
451 4.3.0 <another.recipient@example.com>: Temporary lookup failure;
from=<check@example.com> to=<another.recipient@example.com>
proto=ESMTP helo=<mx.example.com>
Процедуру проверки
работоспособности желательно повторить на всех узлах кластера Kaspersky Secure
Mail Gateway.
Комментарии
Отправить комментарий