LDAP в mailcow подключён, а ящики сотрудников не создаются: Attribute Mapping и квоты домена

Test Connection в LDAP-настройках mailcow зелёный, а ящик нового сотрудника всё равно не появляется. В большинстве случаев дело не в самом LDAP-соединении, а в Attribute Mapping, лимите Max. possible mailboxes или квоте домена. Показываю, в каком порядке я это проверяю, и разбираю кейс кинотеатра на 16 рабочих мест, где из двадцати пяти новых учёток ящики получили только девять.

Зелёный Test Connection — это ещё не работающий провижининг

Когда я подключаю LDAP или Active Directory к корпоративной почте на mailcow, первая реакция админа после успешного Test Connection обычно одна: «готово, дальше само подхватится». Это ошибка, из-за которой я потом трачу час на разбор тикета «сотрудник есть в AD, а почты у него нет». Test Connection в System → Configuration → Access → Identity Provider проверяет ровно одну вещь: что mailcow может подключиться к каталогу под указанной учётной записью и биндится. Он ничего не говорит о том, будет ли создан ящик, какой шаблон к нему применится и не упрётся ли создание в лимит домена.

Внешние источники аутентификации — Keycloak, LDAP/AD и Generic OIDC — стали официально доступны в mailcow с релиза 2025-03 (25 марта 2025 года). До этого, в превью-версии начала февраля 2025-го, провижининг был жёстко завязан на один фиксированный атрибут, а в стабильном релизе разработчики сделали сопоставление атрибутов настраиваемым — это и есть Attribute Field и Attribute Mapping, из-за которых чаще всего и рвётся автосоздание ящиков. Источник аутентификации при этом выбирается не глобально, а для каждого пользователя отдельно: часть сотрудников может продолжать логиниться через встроенную SQL-базу mailcow, а часть — через LDAP.

Когда mailcow вообще создаёт LDAP-пользователя

Здесь у админов второе типовое заблуждение: считать, что раз каталог подключён, все пользователи из AD появятся в mailcow одномоментно, как при полноценном импорте. Это не так — и это не тот сценарий, который я разбираю в статье про миграцию на mailcow через imapsync: там речь о разовом переносе писем и ящиков с другого сервера, а здесь — о постоянной синхронизации учёток с работающим каталогом. LDAP-пользователь в mailcow создаётся автоматически в двух случаях: при первом успешном входе через UI, IMAP, POP3, SMTP или SIEVE (если для него нашлось подходящее сопоставление атрибута), либо по расписанию, если включён Import Users.

Username Field — поле, по которому mailcow ищет пользователя при входе, по умолчанию равно mail: то есть ожидается, что у объекта в каталоге атрибут mail содержит именно тот адрес, под которым человек будет логиниться и получать почту. Если у части сотрудников в AD атрибут mail не заполнен или заполнен алиасом, а не основным адресом, вход у них не пройдёт ещё до всякого Attribute Mapping — и на этом этапе я в первую очередь и смотрю, у всех ли нужных объектов вообще стоит mail.

Import Users отвечает за фоновый импорт: если он включён, новые пользователи подтягиваются из LDAP без ожидания первого логина. Sync / Import Interval (min) задаёт период этой синхронизации в минутах, а Periodic Full Sync дополнительно обновляет уже существующих пользователей — то есть подхватывает изменения атрибутов, а не только новых людей. Для компании, где HR заводит сотрудника в AD за день до выхода, я всегда включаю оба параметра: иначе первый ящик появится только в момент, когда человек впервые попробует войти, а до этого письма ему падать некуда.

Attribute Field и Attribute Mapping: где на самом деле рвётся автосоздание

Это самая частая причина «LDAP подключился, а ящиков нет» — и самая недооценённая, потому что она не выдаёт ошибки в интерфейсе, а просто молча ничего не делает. Attribute Field — это LDAP-атрибут, значение которого mailcow будет сопоставлять с шаблоном ящика. В официальном примере из документации используется атрибут otherMailbox со значением default: в поле Attribute Field указывается othermailbox, а в разделе Attribute Mapping значение default привязывается к нужному шаблону ящика. Если у объекта в AD этого атрибута нет вообще или его значение не совпадает ни с одной строкой в Attribute Mapping — пользователь не получает шаблон, а без шаблона создание ящика просто не запускается, без предупреждений и алертов.

Практический вывод: держать один произвольный, слабо документированный атрибут (тот же otherMailbox) как единственный триггер провижининга — рискованно, потому что его легко забыть проставить новому сотруднику. Я обычно выбираю атрибут, который в компании и так заполняется по регламенту при создании учётки — отдел (department) или employeeType, — и завожу привычку у HR/IT: нет нужного значения атрибута — нет почтового ящика, и это первое, что проверяют при жалобе. Отдельно стоит сверить LDAP-фильтр в настройках Identity Provider: слишком узкий фильтр (например, ограничение по OU) тихо исключает часть сотрудников из выборки ещё до Attribute Mapping, и такие люди не появятся в mailcow ни при каком атрибуте.

Если аутентификация нужна не только для почты, а для целого набора внутренних сервисов, я в части проектов вместо прямого LDAP использую промежуточный SSO. Логика и грабли Attribute Mapping там похожи, но появляется единая точка управления доступом — я подробно разбирал это в статье про развёртывание SSO на Keycloak. Для почтового сервера на 15–20 человек это обычно избыточно, а вот для компании с несколькими системами и десятками сотрудников экономит время именно на подобной диагностике.

Домен переполняется раньше, чем кажется: Max. possible mailboxes и Domain quota

Даже с идеально настроенным Attribute Mapping провижининг может остановиться на объективном лимите: у домена в mailcow есть Max. possible mailboxes — максимальное количество ящиков — и Domain quota — суммарная квота всех ящиков в этом домене в гигабайтах. Официальная диагностика LDAP отдельно требует проверять именно эти два параметра, потому что их легко упустить: домен создавался администратором один раз, до текущего штата, и с тех пор никто не возвращался к его лимитам.

Механика простая, но неочевидная на первый взгляд: если шаблон ящика, который применяет Attribute Mapping, выделяет, скажем, 10 ГБ на пользователя, а суммарная квота домена — 100 ГБ, то создать получится максимум десять ящиков, даже если реальных сотрудников втрое больше. Одиннадцатый и все следующие объекты просто не попадут в mailcow при импорте или входе — без явной ошибки в UI, которую заметит обычный пользователь, только запись в логе. Это не сбой LDAP и не ошибка Attribute Mapping — это арифметика квоты, которую нужно менять руками до массового подключения каталога.

Второй параметр — Max. possible mailboxes — работает независимо от места на диске и может остановить провижининг даже при огромной свободной квоте, если лимит по количеству ящиков был задан заниженным на этапе создания домена «про запас». Я всегда пересчитываю оба лимита перед тем, как включать Import Users на боевом домене, а не после первой жалобы «часть отдела осталась без почты».

Кейс: кинотеатр «Вечерний сеанс», 16 рабочих мест: ящики получили девять новых сотрудников из двадцати пяти

У клиента — кинотеатра «Вечерний сеанс», 16 штатных рабочих мест плюс кассиры и билетёры на сменном графике, всего около тридцати учётных записей в AD, — LDAP к mailcow подключили за час: тест соединения зелёный, первые администраторы вошли без проблем. Через два дня выяснилось, что почту получила только часть сотрудников, а новые кассиры, заведённые перед началом сезона, — нет. Симптом был классический: в LDAP пользователь есть, в mailcow — нет, и ни в интерфейсе, ни у самих сотрудников не было ни одного сообщения об ошибке.

По порядку я проверил: Test Connection — зелёный, домен существует, Attribute Field и Attribute Mapping настроены на department=kassa с шаблоном на 5 ГБ. Дальше стало видно, что домен создавался ещё при первичной настройке почты под пять администраторских ящиков по 10 ГБ: Domain quota — 100 ГБ, Max. possible mailboxes — 14, «с запасом». Пять старых ящиков заняли 50 ГБ квоты, оставшихся 50 ГБ при шаблоне кассиров в 5 ГБ хватало на десять новых ящиков — но раньше сработал лимит по количеству: 14 минус 5 давало ровно девять. Отсюда и цифра «девять из двадцати пяти»: ровно столько успело создаться до упора в Max. possible mailboxes, остальные тихо не провижинились ни при первом логине, ни при плановой синхронизации. А если бы подняли только счётчик ящиков, через одного сотрудника упёрлись бы уже в квоту.

Исправление заняло пятнадцать минут: поднял Max. possible mailboxes до 40 (реальные тридцать учёток плюс резерв на сезонный набор), Domain quota — до 300 ГБ (5 × 10 ГБ + 35 × 5 ГБ = 225 ГБ, остальное — запас), включил Periodic Full Sync, чтобы не ждать первого входа каждого кассира. Ящики новых сотрудников появились в течение одного цикла Sync / Import Interval — я поставил его в 15 минут, для маленького штата это комфортный компромисс между нагрузкой на контроллер домена и скоростью появления новых ящиков.

Чек-лист диагностики и что контролировать дальше

Когда приходит жалоба «LDAP настроен, а ящика нет», я иду по одному и тому же порядку, а не гадаю: домен пользователя заведён в mailcow → в объекте LDAP заполнен атрибут, указанный как Username Field (по умолчанию mail) → LDAP-фильтр не отсекает этого пользователя по OU или группе → Attribute Field содержит значение, которое реально прописано в Attribute Mapping → у домена достаточно свободных Max. possible mailboxes и Domain quota под шаблон, который применится. Пять пунктов покрывают подавляющее большинство обращений, и почти всегда причина — в четвёртом или пятом.

Ошибки фонового создания и синхронизации я смотрю в System → Information → Logs → Crontasks — именно там, а не в общих логах UI, видно, что происходило с последним циклом импорта; ошибки входа конкретного пользователя — в System → Information → Logs → mailcow UI. После того как провижининг заработал стабильно, я обычно добавляю почтовый сервер в общий мониторинг компании — не ради LDAP как такового, а чтобы не пропустить рост диска или падение сервиса раньше пользователей; подход к недорогому мониторингу для небольшого офиса я показывал в статье про мониторинг серверов без бюджета, а бэкапы самого mailcow после такой перенастройки домена стоит на всякий случай перепроверить вручную — у контейнера бэкапов есть свой отдельный класс проблем, я разбирал его в статье про нулевой размер архива mailcow.

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