Как настроить клиент LDAP для подключения внешней аутентификации

Подключение к каталогу LDAP

Вы можете подключить ваше приложение JIRA к каталогу LDAP для проверки подлинности, управления пользователями и группами.

Каталог LDAP представляет собой набор данных о пользователях и группах. LDAP (Легкий Протокол Доступа к каталогам) (Lightweight Directory Access Protocol) — это интернет-протокол, который веб-приложения могут использовать для поиска информации об этих пользователях и группах с сервера LDAP.

Мы предоставляем встроенные разъемы для самых популярных серверов каталогов LDAP:

• Microsoft Active Directory
• Сервер Apache Directory (ApacheDS)
• Apple Open Directory
• Сервер каталогов Fedora
• Novell eDirectory
• OpenDS
• OpenLDAP
• OpenLDAP с использованием схемы Posix
• Схема Posix для LDAP
• Sun Directory Server Enterprise Edition (DSEE)
• Общий сервер каталогов LDAP

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

Как установить и настроить клиент LDAP в Ubuntu и CentOS

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

Сначала начните с установки необходимых пакетов, выполнив следующую команду.

Во время установки вам будет предложено ввести информацию о вашем сервере LDAP (укажите значения в соответствии с вашей средой).

Обратите внимание, что автоматически устанавливаемый пакет ldap-auth-config выполняет большинство конфигураций на основе введенных вами данных.

Далее введите имя базы LDAP, для этого вы можете использовать компоненты своих доменных имен, как показано на скриншоте.

Также выберите версию LDAP для использования и нажмите Ok.

Теперь настройте опцию, чтобы позволить вам создавать утилиты паролей и нажмите Yes

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

Также определите учетную запись LDAP для root и нажмите Ok.

Затем введите пароль для использования, когда ldap-auth-config пытается войти в каталог LDAP, используя учетную запись LDAP пользователя root.

Результаты диалога будут сохранены в файле /etc/ldap.conf.

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

Затем настройте профиль LDAP для NSS, запустив.

Затем настройте систему на использование аутентификации LDAP, обновив конфигурации PAM.

В меню выберите LDAP и любые другие необходимые вам механизмы аутентификации.

Теперь вы должны войти в систему, используя учетные данные на основе LDAP.

Если вы хотите, чтобы домашний каталог пользователя создавался автоматически, вам необходимо выполнить еще одну настройку в файле PAM общего сеанса.

Добавьте эту строку в него.

Сохраните изменения и закройте файл.

Затем перезапустите службу NCSD (Name Service Cache Daemon) с помощью следующей команды.

Примечание. Если вы используете репликацию, клиенты LDAP должны будут ссылаться на несколько серверов, указанных в /etc/ldap.conf.

Вы можете указать все серверы в этой форме:

Это означает, что время ожидания запроса истечет, и если поставщик (ldap1.example.com) перестанет отвечать на запросы, получатель (ldap2.example.com) попытается связаться для его обработки.

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

Если приведенная выше команда отображает сведения об указанном пользователе из файла /etc/passwd, ваш клиентский компьютер теперь настроен для аутентификации на сервере LDAP, вы сможете войти в систему с использованием учетных данных на основе LDAP.

Найти больше доменов DNS, связанных с AD

Я взломал быстрый и грязный пакетный файл, так что мне не нужно запоминать имена доменов DNS и /или им нужно набирать их все. (Список может быть неполным.)

Работает с подключенными к домену машинами. Если ваш компьютер не подключен к домену, вы должны вручную установить USERDNSDOMAIN для того, что вы хотите.

Устранение ошибки AD Replication Error 8606

Устаревший объект (lingering object) – это объект, который присутствует на DC, но был удален на одном или нескольких других DC. Ошибка репликации AD 8606 и ошибка 1988 в событиях Directory Service – хорошие индикаторы устаревших объектов. Важно учитывать, что можно успешно завершить репликацию AD и не регистрировать ошибку с DC, содержащего устаревшие объекты, поскольку репликация основана на изменениях. Если объекты не изменяются, то реплицировать их не нужно. По этой причине, выполняя очистку устаревших объектов, вы допускаете, что они есть у всех DC (а не только DCs logging errors).

Чтобы устранить проблему, в первую очередь убедитесь в наличии ошибки, выполнив следующую команду Repadmin на DC1:

Вы увидите сообщение об ошибке, как показано на экране 11. Кроме того, вы увидите событие с кодом в Event Viewer DC1 (см. экран 12). Обратите внимание, что событие с кодом 1988 только дает отчет о первом устаревшем объекте, который вам вдруг встретился. Обычно таких объектов много.

Экран 11. Ошибка из-за наличия устаревшего объекта

Экран 12. Событие с кодом 1988

Вы должны скопировать три пункта из информации об ошибке 1988 в событиях: идентификатор globally unique identifier (GUID) устаревшего объекта, сервер-источник (source DC), а также уникальное, или различающееся, имя раздела – distinguished name (DN). Эта информация позволит определить, какой DC имеет данный объект.

Прежде всего, используйте GUID объекта (в данном случае 5ca6ebca-d34c-4f60-b79c-e8bd5af127d8) в следующей команде Repadmin, которая отправляет результаты в файл Objects.txt:

Если вы откроете файл Objects.txt, то увидите, что любой DC, который возвращает метаданные репликации для данного объекта, содержит один или более устаревших объектов. DC, не имеющие копии этого объекта, сообщают статус 8439 (уникальное имя distinguished name, указанное для этой операции репликации, недействительно).

Затем вам нужно, используя GUID объект Directory System Agent (DSA) DC1, идентифицировать все устаревшие объекты в разделе Root на DC2. DSA предоставляет доступ к физическому хранилищу информации каталога, находящейся на жестком диске. В AD DSA – часть процесса Local Security Authority. Для этого выполните команду:

В Showrepl.txt GUID объект DSA DC1 появляется вверху файла и выглядит следующим образом:

Ориентируясь на эту информацию, вы можете применить следующую команду, чтобы удостовериться в существовании устаревших объектов на DC2, сравнив его копию раздела Root с разделом Root DC1.

Далее вы можете просмотреть журнал регистрации событий Directory Service на DC2, чтобы узнать, есть ли еще какие-нибудь устаревшие объекты. Если да, то о каждом будет сообщаться в записи события 1946. Общее число устаревших объектов для проверенного раздела будет отмечено в записи события 1942.

Вы можете удалить устаревшие объекты несколькими способами. Предпочтительно использовать ReplDiag.exe. В качестве альтернативы вы можете выбрать RepAdmin.exe.

Используем ReplDiag.exe. С вашей рабочей станции администратора в корневом домене леса, а в нашем случае это Win8Client, вы должны выполнить следующие команды:

Первая команда удаляет объекты. Вторая команда служит для проверки успешного завершения репликации (иными словами, ошибка 8606 больше не регистрируется). Возвращая команды Repadmin /showobjmeta, вы можете убедиться в том, что объект был удален из всех, что объект был удален DC. Если у вас есть контроллер только для чтения read-only domain controller (RODC) и он содержал данный устаревший объект, вы заметите, что он все еще там находится. Дело в том, что текущая версия ReplDiag.exe не удаляет объекты из RODC. Для очистки RODC (в нашем случае, ChildDC2) выполните команду:

После этого просмотрите журнал событий Directory Service на ChildDC2 и найдите событие с кодом 1939. На экране 13 вы видите уведомление о том, что устаревшие объекты были удалены.

Экран 13. Сообщение об удалении устаревших объектов

Используем RepAdmin.exe. Другой способ, позволяющий удалить устаревшие объекты – прибегнуть к помощи RepAdmin.exe. Сначала вы должны удалить устаревшие объекты главных контроллеров домена (reference DC) с помощью кода, который видите в листинге 1. После этого необходимо удалить устаревшие объекты из всех остальных контроллеров домена (устаревшие объекты могут быть показаны или на них могут обнаружиться ссылки на нескольких контроллерах домена, поэтому убедитесь, что вы удалили их все). Необходимые для этой цели команды приведены в листинге 2.

Как видите, использовать ReplDiag.exe гораздо проще, чем RepAdmin.exe, поскольку вводить команд вам придется намного меньше. Ведь чем больше команд, тем больше шансов сделать опечатку, пропустить команду или допустить ошибку в командной строке.

Все компьютеры:

Все компьютеры с определенной ОС:

Вместо Windows 7 можно поставить любую требуемую ОС.

Все серверы (компьютеры с серверной ОС):

Все контроллеры домена:

Контроллеры домена, доступные только для чтения:

Все серверы, не являющиеся контроллерами домена:

SQL серверы:

Exchange серверы:

Как установить и настроить клиент LDAP в Ubuntu и CentOS

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

Сначала начните с установки необходимых пакетов, выполнив следующую команду.

Во время установки вам будет предложено ввести информацию о вашем сервере LDAP (укажите значения в соответствии с вашей средой).

Обратите внимание, что автоматически устанавливаемый пакет ldap-auth-config выполняет большинство конфигураций на основе введенных вами данных.

Далее введите имя базы LDAP, для этого вы можете использовать компоненты своих доменных имен, как показано на скриншоте.

Также выберите версию LDAP для использования и нажмите Ok.

Теперь настройте опцию, чтобы позволить вам создавать утилиты паролей и нажмите Yes

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

Также определите учетную запись LDAP для root и нажмите Ok.

Затем введите пароль для использования, когда ldap-auth-config пытается войти в каталог LDAP, используя учетную запись LDAP пользователя root.

Результаты диалога будут сохранены в файле /etc/ldap.conf.

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

Затем настройте профиль LDAP для NSS, запустив.

Затем настройте систему на использование аутентификации LDAP, обновив конфигурации PAM.

В меню выберите LDAP и любые другие необходимые вам механизмы аутентификации.

Теперь вы должны войти в систему, используя учетные данные на основе LDAP.

Если вы хотите, чтобы домашний каталог пользователя создавался автоматически, вам необходимо выполнить еще одну настройку в файле PAM общего сеанса.

Добавьте эту строку в него.

Сохраните изменения и закройте файл.

Затем перезапустите службу NCSD (Name Service Cache Daemon) с помощью следующей команды.

Примечание. Если вы используете репликацию, клиенты LDAP должны будут ссылаться на несколько серверов, указанных в /etc/ldap.conf.

Вы можете указать все серверы в этой форме:

Это означает, что время ожидания запроса истечет, и если поставщик (ldap1.example.com) перестанет отвечать на запросы, получатель (ldap2.example.com) попытается связаться для его обработки.

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

Если приведенная выше команда отображает сведения об указанном пользователе из файла /etc/passwd, ваш клиентский компьютер теперь настроен для аутентификации на сервере LDAP, вы сможете войти в систему с использованием учетных данных на основе LDAP.

Схемы LDAP

По умолчанию OpenLDAP включает уже готовые схемы. Схемы — это структуры, определяющие объекты, используемые в системе каталогов. Схемы включают в себя классы объектов, у каждого класса есть определенный набор атрибутов. Каждая запись может относиться к одному или нескольким классам и, соответственно, иметь те наборы атрибутов, которые включены в соответствующие классы. В терминологии LDAP классы так и называются — ObjectClass. Вот несколько классов объектов, которые можно использовать:

top
organization
organizationalUnit
person
inetOrgPerson

При создании объекта вы указываете, к каким классам он относится и, исходя из этого, можно задавать соответствующие атрибуты. Примеры чуть ниже. Файлы схем хранятся в директории /etc/ldap/slapd.d/cn=config/cn=schema. В них хранятся описания классов объектов и атрибутов. Для просмотра объектов, которые используются в данный момент, используется команда

Она выводит содержимое базы данных объектов.

Редактировать файлы схемы не рекомендуется. Хотя в интернете достаточно много статей по настройке LDAP, где рекомендуют отредактировать ldif-файлы схемы, это делать не нужно, более того, в самих файлах указан комментарий о том, что файлы нельзя редактировать вручную и необходимо для редактирования использовать команду ldapmodify. К сожалению, информации об использовании этой команды гораздо меньше, чем о ручном редактировании файлов .ldif, хотя ее использование в чем-то даже проще, чем редактирование файлов напрямую.

Как принудительно запустить репликацию Active Directory

Бывают ситуации, когда вам необходимо произвести форсированное обновление на контроллере домена. Для этого есть специальный ключ /syncall. Для того, чтобы выполнить синхронизацию нужного контроллера домена со всеми его партнерами по репликации, вам необходимо на нем выполнить команду:

На выходе вы получите статус репликации и количество ошибок, выглядит это вот так:

СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: 007a5ee4-a454-4029-bc9b-0c4a8b4efbd1._msdcs.root.pyatilistnik.org
Кому: 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Следующая репликация успешно завершена:
От: 007a5ee4-a454-4029-bc9b-0c4a8b4efbd1._msdcs.root.pyatilistnik.org
Кому: 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: a76336ac-2fe6-4dc8-b9d3-23a5b0d22b77._msdcs.root.pyatilistnik.org
Кому: 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Следующая репликация успешно завершена:
От: a76336ac-2fe6-4dc8-b9d3-23a5b0d22b77._msdcs.root.pyatilistnik.org
Кому: 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Сейчас выполняется следующая репликация:
От: 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
Кому: 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Следующая репликация успешно завершена:
От: 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org
Кому: 92925497-671b-44f0-8d13-420fc4d5bbd1._msdcs.root.pyatilistnik.org
СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Завершена операция SyncAll.
Команда SyncAll завершена без ошибок.

Если имеются какие-то проблемы, то вы можете увидеть подобного рода ошибки:

Функция SyncAll сообщает о следующих ошибках:
Ошибка обращения к серверу 5fc9cc16-b994-426d-81c8-c9ff27f29976._msdcs.root.pyatilistnik.org (сетевая ошибка): 17
ba):
Сервер RPC недоступен.

так же repadmin /syncall имеет ряд флагов:

• /a — прерывается, если какой-либо сервер недоступен.
• /A — Синхронизирует все контексты именования, хранящиеся на домашнем сервере
• /d — Идентифицирует серверы по отличительным именам в сообщениях.

• /e — Синхронизирует контроллеры домена на всех сайтах предприятия. По умолчанию эта команда не синхронизирует контроллеры домена на других сайтах.
• /h — Отображение справки.
• /i — запускает бесконечный цикл синхронизации
• /I — Запускает команду repadmin /showrepl на каждой паре серверов вместо синхронизации.
• /j — Синхронизирует только соседние серверы.
• /p — Пауза после каждого сообщения, чтобы пользователь мог прервать выполнение команды.
• /P — Выдвигает изменения наружу от указанного контроллера домена.
• /q — Работает в тихом режиме, который подавляет сообщения обратного вызова.
• /Q — Работает в очень тихом режиме, который сообщает только о фатальных ошибках.

• /s — не синхронизируется.
• /S — Пропускает начальную проверку ответа сервера.

Предположим, что вы внесли важное изменение в AD и хотите его максимально быстро распространить. для этого запустите на актуальном контроллере:

Виртуальные пользователи LDAP

Для получения почты нам осталось настроить виртуальные ящики, информация о которых хранится в LDAP. Для этого выполним настройку Postfix и Dovecot.

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

groupadd -g 1024 vmail

useradd -d /home/mail -g 1024 -u 1024 vmail

* первой командой мы создаем группу vmail с идентификатором 1024. Вторая команда создает пользователя vmail с домашней директорией /home/mail и идентификатором 1024; пользователь входит в группу vmail, созданную первой командой. В вашей системе идентификатор 1024 может быть уже занят — в этом случае меняем его на другой номер и ниже по инструкции заменяем значение 1024 на свое.

Создаем домашнюю директорию для пользователя:

Задаем в качестве владельца нашего созданного пользователя:

chown vmail:vmail /home/mail

Мы будем хранить всю почту пользователей в каталоге /home/mail.

Для систем на базе Debian (Ubuntu) нужно также установить postfix-ldap:

apt-get install postfix-ldap

Открываем конфигурационный файл postfix:

Добавляем следующие строки:

virtual_transport = dovecot
virtual_minimum_uid = 1024
virtual_uid_maps = static:1024
virtual_gid_maps = static:1024
virtual_mailbox_base = /home/mail
virtual_mailbox_domains = dmosk.local dmosk.ru
virtual_alias_maps = ldap:/etc/postfix/ldap_virtual_alias_maps.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap_virtual_mailbox_maps.cf

• virtual_transport — указывает куда дальше должна передаваться полученная почта для обработки. В нашем примере, после постфикса она отправится в dovecot.
• virtual_minimum_uid — с какого номера присваивать идентификаторы пользователям.
• virtual_uid_maps — от какого идентификатора пользователя будет работать доставка сообщений. В нашем примере это 1024, который присвоен пользователю vmail.
• virtual_gid_maps — идентификатор группы пользователя для доставки сообщений — 1024 (vmail).
• virtual_mailbox_base — каталог, где будут храниться почтовые ящики пользователей и сами письма.
• virtual_mailbox_domains — домены, для которых наш сервер будет принимать почту. Если их несколько, перечисляем через пробел.
• virtual_alias_maps — путь хранения алиасов для виртуальных пользователей, а также формат хранения — в нашем случае ldap.
• virtual_mailbox_maps — формат и путь хранения почтовых ящиков для виртуальных пользователей.

В нашем конфиге создано 2 карты для получения данных из AD — ldap_virtual_alias_maps.cf и ldap_virtual_mailbox_maps.cf. Создаем эти файлы с описанием того, как нужно извлекать данные.

Создаем файл для получения алиасов:

version = 3
server_host = ldap://dmosk.local/
search_base = ou=Пользователи,dc=dmosk,dc=local
query_filter = (&(objectClass=person)(mail=%s))
result_attribute = mail
scope = sub
bind = yes
bind_dn = cn=postfix,cn=Users,dc=dmosk,dc=local
bind_pw = dmosk.ru135

Создаем файл для получения почтовых ящиков:

version = 3
server_host = ldap://dmosk.local/
search_base = ou=Пользователи,dc=dmosk,dc=local
query_filter = (&(objectClass=person)(mail=%s))
result_filter = %s
result_attribute = mail
special_result_attribute = member
scope = sub
bind = yes
bind_dn = cn=postfix,cn=Users,dc=dmosk,dc=local
bind_pw = dmosk.ru135

* где для обоих файлов:

• version — версия ldap. Как правило, третья.
• server_host — имя нашего сервера ldap (в моем примере указан домен, так как по нему у меня разрешается кластер LDAP).
• search_base — базовый контейнер, в котором мы ищем наших пользователей.
• query_filter — фильтр для поиска учетных записей пользователей. Формат зависит от того, какую реализацию для LDAP мы используем.
• result_filter — (или result_format) формат для вывода найденных результатов. Рассмотрим возможные варианты для master@dmosk.local:
  • %s — возвращает результат как есть, то есть, master@dmosk.local.
  • %u — упускает домен, то есть, master.
  • %d — возвращает доменную часть, то есть, dmosk.local.
  • sub — во всех вложенных контейнерах.
  • base — только в контейнере, который указан в base.
  • one — во всех вложенных контейнерах, но на один уровень.

  Открываем для редактирования файл:

  submission inet n — n — — smtpd
  -o smtpd_tls_security_level=may
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=/var/spool/postfix/private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o smtpd_sasl_local_domain=$myhostname

  smtps inet n — n — — smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

  dovecot unix — n n — — pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d $
  #flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -d $

  * необходимо убедиться, что в содержимом файла нет других раскомментированных опций для submission, smtps и dovecot (по умолчанию, их нет). В данном случае, мы настроили работу postfix на портах 25, 465 и 587. В файле master.cf мы настраиваем работу вспомогательных сервисов для Postfix. Описание каждого сервиса начинается с новой строки без отступа. Затем идут настройки для сервиса и параметры запуска. Для примера, рассмотрим первую добавленную строку —
  submission inet n — n — — smtpd:

  • submission — имя сервиса. Возможно использование заранее определенных в postfix служб или создание своих. В данном примере submission для подключения MUA по порту 587 при отправке почты.
  • inet — тип обслуживания. Возможны варианты inet (сокет TCP/IP), unix (потоковый сокет), unix-dgram (сокет дейтаграммы), fifo (именованный канал очереди), pass (потоковый сокет UNIX-домена).
  • первый «n» — является ли сервис частным и должен быть ограниченным. Возможны варианты y или n. Для типа обслуживания inet может быть только n.
  • первый «-« — работает ли служба с правами root. Возможны варианты y, n и —. Прочерк означает неприменимость данного параметра к конкретному сервису.
  • второй «n» — должна ли служба работать в окружении chroot. Возможны варианты y или n.
  • второй «-« — через какое время в секундах пробудить службу, если она неактивна.
  • третий «-« — максимальное количество одновременно выполняемых процессов, которые может запустить данный сервис.
  • smtpd — выполняемая команда.

  * после команды идут аргументы ее запуска. Они могут переопределять параметры, заданные в main.cf. Каждый аргумент записывается с новой строки и начинается с двух пробелов. В данном примере мы используем следующие аргументы:

  • smtpd_tls_security_level — задает уровень безопасности с применением TLS. В данном примере may говорит о возможности его использования.
  • smtpd_sasl_auth_enable — разрешает sasl аутентификацию.
  • smtpd_sasl_type — указывает тип аутентификации.
  • smtpd_sasl_path — путь до временных файлов обмена информацией с сервером хранения почты (в нашем случае Dovecot). Указывается либо абсолютный путь, либо относительный queue_directory.
  • smtpd_sasl_security_options — дополнительные опции настройки sasl.
  • smtpd_sasl_local_domain — добавить домен для пользователей, которые проходят smtp-аутентификацию.
  • syslog_name — префикс названия службы при занесении ее в системный журнал.
  • smtpd_tls_wrappermode — запускать ли службу в нестандартном режиме (для поддержки TLS).
  • smtpd_client_restrictions — настройки ограничения клиентских соединений. В данном примере разрешить только авторизованных.

  Обтатите внимание на dovecot — в моем примере идут 2 строки с опциями: первая для систем Debian, вторая закомментирована, и она для Red Hat. Вам необходимо оставить комментарий для нужно системы, вторую строку можно закомментировать или удалить.