Сотрудника добавили в Active Directory, а в адресной книге Zimbra его нет: разбираем GAL sync

Сотрудника завели в Active Directory, логин и почта работают, а коллеги не находят его в общей адресной книге Zimbra. Проблема почти всегда не в самом AD, а в GAL sync account — отдельной служебной учётке, через которую Zimbra периодически забирает данные из внешнего каталога. Разбираю, как устроена синхронизация, что проверить командами zmprov и zmgsautil и почему иногда вместо «нет сотрудника» получают обратную проблему — дубликаты в адресной книге.

Что такое GAL sync account и почему без него ничего не работает

GAL (Global Address List) в Zimbra — это общая адресная книга компании, и у неё есть режим работы, заданный атрибутом домена zimbraGalMode: zimbra (только внутренний каталог Zimbra), ldap (только внешний каталог — например, ваш Active Directory или Samba в роли контроллера домена, если каталог развёрнут на Linux) или both, когда используются оба источника одновременно. Если корпоративная почта на Zimbra интегрирована с AD хотя бы частично, обычно выбирают both или ldap, а не полагаются на ручное копирование контактов. Настройка домена — это только половина дела: сама выгрузка данных из AD в GAL выполняется отдельной служебной учётной записью, GAL sync account, которая периодически опрашивает внешний каталог и складывает результат в свою адресную книгу.

GAL sync account — ресурсная учётная запись, лицензию Zimbra она не расходует, и в веб-клиенте именно она даёт листать и постранично просматривать общую адресную книгу при выборе получателей. Создаётся такая учётка не через обычный createAccount, а специальной командой zmgsautil, и начиная с ZCS 8 в ней обязательно указывается mailstore-сервер (ключ -s), на котором она будет жить: для внешнего источника — zmgsautil createAccount -a galsync@example.com -n ExternalGAL --domain example.com -s mail.example.com -t ldap -f _ExternalGAL, для внутреннего — тот же синтаксис с -t zimbra. Ограничение простое и его легко нарушить, разворачивая интеграцию по памяти: на одном mailstore-сервере допускается только одна GAL sync account на домен. Если в компании когда-то тестировали интеграцию и создали вторую учётку «для проверки», а старую не удалили аккуратно, новый сотрудник может не попасть именно в тот источник, который реально опрашивается.

Почему аутентификация через AD работает, а контактов нет

Частая путаница: администратор видит, что новый сотрудник успешно логинится (если в компании настроена аутентификация через Active Directory отдельно от GAL), и делает вывод, что интеграция с AD в порядке. На самом деле это два независимых механизма. Проверка пароля через LDAP bind ничего не говорит о том, работает ли синхронизация адресной книги — это разные подсистемы Zimbra, использующие один и тот же каталог по-разному.

Сама синхронизация GAL идёт по расписанию — интервал опроса хранится на источнике данных (data source) GAL sync account в атрибуте zimbraDataSourcePollingInterval; в примерах Zimbra Tech Center это 1d, то есть раз в сутки. Если сотрудника добавили в AD только что, а очередной цикл синхронизации ещё не наступил, разумно не ждать, а запустить синхронизацию вручную и проверить результат сразу, не гадая, когда сработает следующий автоматический прогон.

Есть и третья причина, которую forceSync не лечит в принципе, — фильтр, которым Zimbra выбирает записи из AD. Встроенный фильтр для Active Directory требует у пользователя заполненного атрибута mailNickname, и Tech Center прямо называет это первым, что нужно проверить, если в GAL попали не все записи из AD. В компаниях без Exchange этот атрибут часто заполняется только скриптом или шаблоном учётки: создали сотрудника вручную в оснастке «Пользователи и компьютеры» — и в адресную книгу он уже не попадает, хотя войти в почту может. Там же в фильтре есть условие !(msExchHideFromAddressLists=TRUE): учётку, скрытую из адресных списков ещё со времён Exchange, Zimbra тоже честно не покажет.

Принудительная синхронизация: zmgsautil forceSync

Команда для ручного запуска синхронизации конкретного источника выглядит так:

zmgsautil forceSync -a galsync@example.com -n ExternalGAL

Параметр -a — адрес самой GAL sync account, -n — имя источника данных (data source), а не домена и не сервера; типичные имена — InternalGAL и ExternalGAL, но в вашей инсталляции они могли быть заданы иначе при создании. Если синхронизация штатно настроена и источник просто не успел дойти до нового сотрудника по расписанию, после forceSync запись должна появиться в адресной книге в течение нескольких минут.

Если после forceSync ничего не изменилось, следующий шаг — убедиться, что источник данных вообще существует и включён:

zmprov gds galsync@example.com

Команда getDataSources выводит все источники учётной записи с их атрибутами, включая zimbraDataSourceEnabled и интервал опроса. Если источник с нужным именем в выводе отсутствует — это уже не вопрос расписания, а более серьёзная проблема: сам объект синхронизации пропал.

No such data source: когда источник синхронизации пропадает

На форуме Zimbra описан случай именно с такой ошибкой — no such data source: ExternalGAL — при попытке принудительной синхронизации внешнего GAL. Источник, который раньше работал, в какой-то момент переставал существовать в списке data source учётной записи, и обычный forceSync возвращал ошибку вместо результата. Решение в том обсуждении было не в перезапуске служб, а в восстановлении самого источника данных и явном включении его через zimbraDataSourceEnabled TRUE — то есть источник нужно было фактически создать заново с теми же параметрами подключения к AD, а не просто «подождать ещё».

Это иллюстрирует важный практический момент: GAL sync account — обычная учётная запись Zimbra со своим набором источников данных, и с ней может случиться всё то же самое, что и с любым другим data source в системе — отключение после сбоя аутентификации на стороне AD, ручное удаление кем-то из администраторов, повреждение при обновлении. Отдельно Tech Center предупреждает: при нескольких источниках ни один из них не должен оставаться с zimbraDataSourceEnabled FALSE — выключенный источник ломает постраничный просмотр и синхронизацию остальных, поэтому ненужный источник лучше удалить, а не отключать. Поэтому при разборе «сотрудника нет в GAL» я всегда сначала смотрю на список источников через zmprov gds, а не сразу лезу проверять сетевую доступность контроллера домена.

Сотрудник не попадает в GAL даже после forceSync: кейс и дубли

Обратная по симптому, но родственная по причине проблема — дубликаты в адресной книге. Если в компании со временем накопилось несколько источников данных, у которых пересекаются области поиска в AD (search base), синхронизация регулярно возвращает одних и тех же людей из разных мест каталога. Zimbra не объединяет такие записи автоматически: с её точки зрения это разные контакты, полученные из разных источников, и совпадение атрибутов ничего не значит.

У условного клиента — антикварного магазина «Вещь с историей», 32 рабочих места — новую сотрудницу отдела оценки завели в AD в понедельник утром, а к вечеру она пожаловалась, что коллеги не находят её в адресной книге при попытке поставить в копию письма поставщикам. Аутентификация у неё работала сразу. Проверка zmprov gd example.com zimbraGalMode вернула both, zmprov gds galsync@example.com показал единственный источник ExternalGAL с zimbraDataSourceEnabled TRUE и интервалом 1d. Логично было решить, что синхронизация просто не дошла по расписанию, но ручной zmgsautil forceSync -a galsync@example.com -n ExternalGAL ничего не изменил — сотрудницы в GAL по-прежнему не было.

Разгадка нашлась в самом AD. Все прежние учётки магазина создавались PowerShell-скриптом прежнего администратора, который заполнял mailNickname, а новую сотрудницу завела офис-менеджер вручную через оснастку — атрибут остался пустым, и встроенный AD-фильтр Zimbra её просто не выбирал. У нас было два пути: убрать требование mailNickname, задав собственный zimbraGalLdapFilter на домене или источнике (Tech Center описывает этот обход как безопасный, но менять фильтр по умолчанию в глобальной конфигурации не рекомендует), либо заполнить атрибут. Я выбрал второе — меньше расхождений с документированной конфигурацией. Заполнили mailNickname, повторили forceSync, и через пару минут сотрудница появилась в адресной книге; весь разбор занял около сорока минут. Пункт «заполнить mailNickname» теперь стоит в чек-листе приёма сотрудника, а длинный интервал опроса оставили — для разовых случаев проще запустить forceSync, чем дёргать контроллер домена частым опросом.

Обычная причина пересечения областей поиска — источники синхронизации, настроенные исторически «на всякий случай» с разными, но перекрывающимися search base, или тестовая GAL sync account, оставшаяся рядом с боевой после пилота интеграции. Раз на mailstore-сервере допускается лишь одна GAL sync account на домен, при находке двух активных источников с похожими областями поиска я в первую очередь смотрю, не осталась ли одна из них артефактом старой настройки. Саму настройку GAL sync, к слову, я делаю сразу при развёртывании корпоративного почтового сервера Zimbra, чтобы таких артефактов не появлялось. Практическое решение по дублям, которое предлагает и Tech Center, — найти в GAL sync account папки контактов, где лежит дубль, сузить search base каждого источника до непересекающейся части каталога (например, конкретных OU в AD) и заново прогнать forceSync после правки; ранее созданные дубликаты автоматически не пересчитаются и удаляются отдельно.

Что проверить по порядку, когда сотрудника нет в GAL

Порядок диагностики, который экономит время: сначала убедитесь, что домен вообще настроен на внешний каталог — zmprov gd example.com zimbraGalMode должен вернуть both или ldap, а не zimbra. Затем проверьте, что GAL sync account существует и на нужном сервере, посмотрите список её источников через zmprov gds, после этого запустите принудительную синхронизацию командой forceSync, а если и она не помогла — сравните атрибуты пропавшего сотрудника в AD (mailNickname, msExchHideFromAddressLists) с теми, кто в GAL есть. И ещё одна деталь из Tech Center: если поиск по GAL пропускает первый внешний источник, проверьте, что на домене стоит zimbraGalMode both — первый внешний источник наследует настройки внешнего GAL домена.

Если после всех проверок сотрудник появляется, но с опозданием и без части атрибутов (например, без телефона или должности), стоит свериться с тем, что именно синхронизируется с AD-стороны: маппинг атрибутов GAL sync account настраивается отдельно и не всегда совпадает с полным набором полей учётной записи в каталоге. Это уже тонкая настройка конкретного источника, а не типовая поломка — но начинать разбор всё равно нужно с тех же трёх команд. Если же вместо пропавшего сотрудника у вас регулярно сыплются ошибки индекса при поиске в почте — это уже другая, хоть и похожая по духу проблема; про неё у меня отдельный разбор возможно повреждённого индекса и переиндексации в Zimbra.

• zmprov gd <domain> zimbraGalMode — режим GAL домена: zimbra / ldap / both
• zmprov gds galsync@<domain> — список источников синхронизации и их состояние
• zmgsautil forceSync -a galsync@<domain> -n <source> — принудительный запуск
• mailNickname в AD — встроенный AD-фильтр Zimbra без него не выбирает учётку
• zimbraDataSourceEnabled TRUE — источник должен быть включён, иначе forceSync не поможет
• Search base каждого источника — не должен пересекаться с другими, иначе будут дубли

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