LDAP и почтовый сервер: как перевести пользователей и пароли при переезде без массового сброса

Облако не отдаст вам даже пароли ваших собственных сотрудников. Это лучшая иллюстрация того, кому на самом деле принадлежат ваши учётные записи. Пароли сотрудников — первое, что облако не отдаёт: они принадлежат провайдеру, и выгрузить их нельзя. Это ещё одно напоминание, что в облаке компания арендует даже собственные учётные записи. LDAP и свой почтовый сервер решают проблему иначе: почта проверяет пароль в каталоге компании, и сотрудник входит в почту тем же паролем, что и в компьютер. Разбираем, как перевести пользователей при переезде без хаоса с массовой сменой паролей.

Почему пароли не переносятся

Облачный провайдер хранит не сами пароли, а их хэши в своём формате, и не выдаёт их ни через API, ни по запросу. Это правильно с точки зрения безопасности, но означает одно: при любом переезде из облака у каждого сотрудника будет новый пароль от почты. Других вариантов нет — кроме одного: чтобы пароль от почты перестал быть отдельным паролем.

Когда почтовый сервер проверяет пароль в каталоге компании — Active Directory или LDAP, — пароль от почты совпадает с паролем от рабочего компьютера. Переезд почты перестаёт быть поводом для смены паролей, а увольнение сотрудника — блокировкой в десяти местах: блокируете учётную запись в каталоге, и почта закрывается вместе со всем остальным.

Ваши сотрудники — не ваши учётные записи

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

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

Варианты

Варианты сочетаются. Типичная схема для компании с доменом Windows: вход в почту по паролю из AD, единый вход для веб-почты через Keycloak, пароли приложений для телефонов.

Вариант 1. Новые пароли без каталога

Для офиса до 10–15 человек без домена Windows проще всего задать новые пароли на почтовом сервере. Чтобы это не превратилось в хаос, сделайте так: администратор генерирует длинные случайные пароли, раздаёт их лично или через менеджер паролей — не почтой и не в общем чате, — и в первый вход сотрудник меняет пароль на свой. Сроки — в последний рабочий день перед переключением, чтобы в понедельник все вошли сразу.

Облачные пароли не переиспользуйте. Если пароль утёк когда-то в облаке, на новом сервере он не должен работать.

Вариант 2. Active Directory или LDAP

Если в компании есть домен Windows, почтовый сервер можно научить проверять пароли в нём. Принцип одинаков для всех сборок: почтовые службы при входе обращаются к каталогу по LDAP, проверяют логин и пароль и при успехе пускают в ящик. В Dovecot это настраивается как источник паролей LDAP; в mailcow — через встроенную интеграцию с внешним поставщиком учётных записей; в iRedMail — по инструкции интеграции с AD; в Carbonio — внешней аутентификацией домена.

# Dovecot: проверка паролей в каталоге (фрагмент, общий вид)
passdb ldap {
  ldap_uris = ldaps://dc1.company.local
  ldap_base = OU=Staff,DC=company,DC=local
  ...
}

Подключение к каталогу — только по защищённому протоколу LDAPS или с StartTLS, и под отдельной служебной учётной записью с правами только на чтение. Служебный пароль — в сейфе паролей, не в открытом виде в конфигурации, которую кто-то может скопировать.

Что берётся из каталога

Кроме пароля, из каталога удобно брать атрибуты: адрес почты, имя, отдел, членство в группах. Тогда ящик создаётся автоматически при первом входе сотрудника или по расписанию синхронизации, а рассылки отделов собираются из групп каталога. Новый сотрудник, заведённый в AD, сразу получает почту; уволенный — сразу её теряет.

Здесь же и типичная проблема: ящики не создаются, потому что фильтр выборки пользователей или атрибут с адресом указаны неточно. Мы разбирали это в статье «mailcow: ящики из LDAP не создаются».

Вариант 3. Единый вход через Keycloak

Если у компании много внутренних веб-сервисов — CRM, портал, система заявок, веб-почта, — разумно сделать единый вход: сотрудник входит один раз в Keycloak, и все сервисы его узнают. Keycloak берёт пользователей из AD или LDAP и даёт сервисам вход по OpenID Connect или SAML. Веб-почта mailcow, SOGo, Roundcube и Carbonio поддерживают такой вход в той или иной форме.

Важное ограничение: единый вход работает для веб-интерфейсов. Почтовые программы и телефоны по IMAP и SMTP в большинстве случаев продолжают входить по паролю. Подробно о Keycloak — в статье о едином входе в корпоративные сервисы через Keycloak, сравнение с альтернативой — в статье «Authentik или Keycloak».

Вариант 4. Пароли приложений

Телефоны и почтовые программы хранят пароль на устройстве. Если это основной пароль из AD, его кража с телефона даёт доступ ко всему — компьютеру, VPN, порталу. Пароли приложений решают это: для каждого устройства создаётся отдельный пароль, который работает только для IMAP и SMTP, и его можно отозвать, не трогая основной. Потерял телефон — отозвал один пароль.

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

Создание пароля приложения сотрудник делает сам в веб-почте или в портале: выбирает название устройства, получает пароль, вводит его в телефон. Администратору остаётся следить, чтобы старые неиспользуемые пароли приложений периодически удалялись — список с датой последнего использования есть в большинстве сборок.

Порядок при переезде

Последовательность, при которой никто не останется без почты.

• заранее: подключить сервер к каталогу, проверить вход на тестовых учётных записях
• за неделю: проверить, что у всех сотрудников в каталоге заполнен адрес почты
• за 2–3 дня: создать или синхронизировать ящики, перенести письма
• за день: разослать инструкцию — вход тем же паролем, что в компьютер
• день переключения: сотрудники входят в веб-почту привычным паролем
• первая неделя: на телефонах — пароли приложений вместо основного пароля

Без каталога сейчас — с каталогом потом

Если каталога нет, а компания растёт, переезд почты — хороший повод его завести. Domain Controller на Samba или Windows Server, либо облегчённый LDAP-каталог, даёт одно место, где заводятся и блокируются сотрудники. Почта, файлы, VPN, Wi-Fi и внутренние сервисы подключаются к нему по очереди. Это ещё один шаг от разрозненных облачных аккаунтов к своей инфраструктуре.

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

Как проверить вход до переключения

Прежде чем рассылать сотрудникам инструкцию, проверьте вход на нескольких реальных учётных записях — с их согласия или на тестовых. В Dovecot есть команда, которая проверяет пароль через настроенный источник и показывает, что вернул каталог.

doveadm auth test anna@company.ru
# passdb: anna@company.ru auth succeeded — пароль проверен в каталоге

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

Кто живёт вне каталога

Не всё в почте — люди. Общие ящики, служебные учётные записи для 1С, сканеров и сайта, ящики подрядчиков часто не нужно заводить в каталоге компании. Почтовые серверы позволяют держать такие учётные записи локально, с собственными паролями, рядом с пользователями из каталога. Решите заранее, какие учётные записи где живут, и запишите это: через год иначе никто не вспомнит, почему у сканера отдельный пароль.

Смена пароля и кэш

Когда почта проверяет пароль в каталоге, сотрудник меняет его привычным способом — на компьютере или в портале самообслуживания, а не в веб-почте. Предупредите об этом: в веб-почте кнопка смены пароля либо пропадёт, либо будет вести не туда.

Почтовые службы кэшируют результат проверки пароля на несколько минут, чтобы не нагружать каталог. После смены пароля старый может работать ещё какое-то время, а новый — не сразу; телефоны с сохранённым старым паролем начнут получать ошибки входа. Это нормально, но об этом стоит сказать сотрудникам, иначе первая смена пароля обернётся звонками.

Второй фактор

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

Увольнение сотрудника

С каталогом порядок короткий: учётная запись блокируется в каталоге, и вход в почту закрывается вместе со всем остальным. Но пароли приложений, если они хранятся в почтовом сервере, нужно отозвать отдельно — проверьте, как это устроено в вашей сборке. Переписку уволенного передайте преемнику, адрес сделайте псевдонимом, правила пересылки в ящике проверьте и удалите.

Что написать сотрудникам

Инструкция на одну страницу снимает большую часть вопросов в день переключения. В ней должно быть: с какого дня почта работает на новом сервере; адрес веб-почты; что входить нужно тем же логином и паролем, что и в рабочий компьютер; как подключить телефон и где создать пароль приложения; куда обращаться, если не получается. Отдельной строкой — что старые пароли от облачной почты больше не нужны и вводить их никуда не надо: это защищает от фишинговых писем «подтвердите пароль от почты», которые часто приходят как раз во время переездов.

Что меняется для администратора

Для администратора переход на каталог — это одно место вместо нескольких. Новый сотрудник заводится в каталоге — и получает компьютер, почту, VPN и доступ к порталу. Перевод в другой отдел — смена группы, и рассылки отделов обновляются сами. Увольнение — одна блокировка. В облаке каждое из этих действий делалось отдельно в панели провайдера, и каждое можно было забыть.

Цена этого удобства — каталог нужно беречь и копировать так же тщательно, как почту: без него никто не войдёт никуда.

Безопасность каталога

Когда пароль от почты — это пароль из каталога, каталог становится главным активом. Его защита важнее защиты почты: сложные пароли с регулярной проверкой на утечки, блокировка после неудачных попыток, отдельные учётные записи администраторов, журнал входов. Перебор паролей по почтовым протоколам бьёт прямо в каталог, поэтому на почтовом сервере обязательно ограничение попыток входа — иначе боты будут блокировать учётные записи сотрудников в AD. Базовые меры — в статье «Защита Active Directory за 12 шагов».

Типичные ошибки

Все встречались нам в реальных проектах.

• подключение к каталогу без шифрования — пароли идут по сети открытым текстом
• служебная учётная запись с правами администратора домена
• перебор паролей через почту блокирует учётные записи в AD — нет Fail2ban
• на телефонах основной пароль из AD — кража телефона даёт доступ ко всему
• адрес почты не заполнен в каталоге — ящик не создаётся
• пароли разосланы почтой на старые облачные ящики

Итог

Облако заставляет компанию вести отдельные пароли от почты, которые нельзя забрать с собой. Свой сервер с каталогом делает почту частью вашей инфраструктуры: один пароль, одна точка блокировки, полный контроль. Общий порядок переезда — в руководстве по переносу почты с Яндекс 360.

Частые вопросы