Переход с локальных пользователей на LDAP в Zabbix: пошаговая миграция без остановки мониторинга

Миграция аутентификации в Zabbix с локальных учетных записей на централизованный LDAP или Active Directory — это критически важная задача, ошибка в которой может заблокировать доступ к системе мониторинга для всей команды. В этой статье вы получите проверенный, пошаговый план, который гарантирует плавный переход без остановки сбора метрик и работы оповещений. Мы разберем не только техническую настройку, но и обязательные подготовительные шаги, стратегию параллельной работы двух систем и четкую процедуру отката на случай непредвиденных проблем.

Следуя этой инструкции, вы исключите риск остаться без доступа к Zabbix, обеспечите непрерывность мониторинга и получите готовые примеры конфигурации для Zabbix 6.0 LTS и 7.0. Основной принцип — «включить, протестировать, а затем переключить» — позволит провести миграцию контролируемо и безопасно.

Подготовка к миграции: основа для безопасного перехода

Успешная миграция на 90% зависит от качественной подготовки. Пропуск этих шагов — прямая дорога к аварийной ситуации в рабочее время. Философия «измерь дважды, отрежь один раз» здесь как никогда актуальна. Перед любыми изменениями в настройках аутентификации выполните следующие обязательные действия.

1. Проверка и запись текущей версии Zabbix. Убедитесь, что вы работаете с поддерживаемой версией (6.0 LTS или 7.0). Базовая процедура идентична, но интерфейс может незначительно отличаться. Проверить версию можно в правом нижнем углу веб-интерфейса или командой zabbix_server -V на сервере.

2. Полное резервное копирование. Создайте резервные копии, с которых можно будет восстановить систему в исходное состояние.

База данных: Выполните дамп всей базы данных Zabbix.

# Для MySQL/MariaDB
mysqldump -u [user] -p[password] zabbix > zabbix_backup_$(date +%Y%m%d).sql

# Для PostgreSQL
pg_dump -U [user] zabbix > zabbix_backup_$(date +%Y%m%d).sql

Конфигурационные файлы: Скопируйте ключевые конфиги.

cp /etc/zabbix/zabbix_server.conf /etc/zabbix/zabbix_server.conf.backup
cp /etc/zabbix/web/zabbix.conf.php /etc/zabbix/web/zabbix.conf.php.backup

3. Аудит существующих пользователей. Экспортируйте список локальных пользователей, их роли и членство в группах. Это можно сделать через веб-интерфейс (Administration → Users) или прямым запросом к БД: SELECT alias, name, roleid FROM users;. Это понадобится для сверки прав после миграции.

4. Согласование окна изменений. Даже при планировании нулевого простоя согласуйте работы на время, когда активность пользователей минимальна (например, ночь или выходные). Это даст запас времени на решение возможных проблем.

Создание аварийной административной учетной записи: ваш страховочный трос

Это non-negotiable шаг, который напрямую отвечает на главный страх — остаться без доступа к Zabbix. Аварийная учетная запись — это локальный пользователь с правами суперадминистратора (Super admin role), пароль от которого известен только ответственному лицу. Она создается ДО любых манипуляций с LDAP и служит «люком» для отката.

Пошаговая инструкция:

В веб-интерфейсе Zabbix перейдите в Administration → Users.
Нажмите Create user.
Задайте уникальное имя пользователя, которое не конфликтует с будущими LDAP-аккаунтами, например, zbx_fallback_admin.
Назначьте роль Super admin.
Укажите сложный пароль и сохраните его в надежном месте (менеджер паролей).
В разделе Media можно добавить email для уведомлений, но это не обязательно для аварийного доступа.
Обязательно протестируйте вход с этими учетными данными в приватном окне браузера, чтобы убедиться, что учетная запись активна.

Эту учетную запись нельзя отключать или удалять до полного завершения миграции и успешной работы всех пользователей через LDAP в течение как минимум одной-двух недель.

Подготовка LDAP-сервера: что должно быть готово на стороне каталога

Прежде чем лезть в настройки Zabbix, соберите все необходимые параметры подключения к вашему LDAP/AD. Это сэкономит время и предотвратит ошибки.

Чек-лист для администратора LDAP/AD:

Сервисная учетная запись (Bind DN). Создайте или выделите специальную учетную запись, от имени которой Zabbix будет подключаться к каталогу для поиска пользователей. Ей нужны минимальные права: только на чтение (read) в тех подразделениях (OU), где находятся учетные записи пользователей. Например: CN=zabbix_svc,OU=Service Accounts,DC=company,DC=com.
Base DN для поиска пользователей. Определите Distinguished Name (DN) контейнера или организационного подразделения, в котором Zabbix будет искать пользователей. Например: OU=Users,DC=company,DC=com. Чем уже scope, тем быстрее поиск.
Проверка доступности. Убедитесь, что с хоста Zabbix-сервера доступны порты LDAP-сервера (обычно 389 для LDAP, 636 для LDAPS). Проверьте командой: telnet ldap.company.com 389 или nc -zv ldap.company.com 636.
Тестовые учетные записи. Подготовьте 2-3 реальные учетные записи пользователей из LDAP, которые будут использоваться для тестирования подключения и прав. Желательно, чтобы они состояли в разных группах (например, одна — в группе IT-Admins, другая — в группе DevOps).

После выполнения этих шагов у вас на руках должен быть список: Bind DN и пароль, Base DN, адрес LDAP-хоста, порт, атрибут для логина пользователя (sAMAccountName для AD, uid для OpenLDAP).

Настройка и тестирование LDAP-аутентификации в параллельном режиме

Теперь наступает ключевая фаза — подключение и тестирование LDAP, при этом локальная аутентификация остается полностью работоспособной. Это фаза «включения, но не переключения», которая обеспечивает непрерывность работы.

Конфигурация в веб-интерфейсе: параметры подключения для Active Directory и OpenLDAP

Перейдите в Administration → Authentication → LDAP settings. Вот практические примеры заполнения полей для двух основных типов серверов.

Для Active Directory:

LDAP host: ad.company.com или IP-адрес контроллера домена.
Port: 636 (рекомендуется для LDAPS) или 389 (для StartTLS).
Base DN: OU=Users,DC=company,DC=com
Bind DN: CN=zabbix_svc,OU=Service Accounts,DC=company,DC=com
Bind password: Пароль сервисной учетной записи.
Search attribute: sAMAccountName (стандартный атрибут логина в AD).
Отметьте галочку StartTLS (если используете порт 389) или выберите LDAPS в настройках подключения (для порта 636).

Для OpenLDAP:

LDAP host: ldap.company.com
Port: 636
Base DN: ou=people,dc=company,dc=com
Bind DN: uid=zabbix_svc,ou=services,dc=company,dc=com
Bind password: Пароль сервисной учетной записи.
Search attribute: uid (или cn, в зависимости от схемы).
Выберите LDAPS.

В поле Test authentication введите логин и пароль одного из подготовленных тестовых пользователей из LDAP и нажмите кнопку Test. Это первая проверка, что bind и поиск работают.

Сопоставление групп LDAP с группами Zabbix: настройка прав доступа

Здесь кроется частая проблема: пользователь успешно входит, но не видит никаких данных или не имеет прав. Механизм прост: Zabbix находит группы, в которых состоит пользователь в LDAP, и сопоставляет их с заранее созданными группами в Zabbix, наследуя их роли.

Пошаговая инструкция:

Создайте группы в Zabbix. В Administration → User groups создайте группы с именами, аналогичными группам безопасности в LDAP/AD. Например: IT-Admins, DevOps, Guests.
Назначьте роли. Для каждой созданной группы назначьте соответствующую роль Zabbix (Admin, Super admin, User и т.д.) и настройте права доступа к хостам.
Настройте маппинг в LDAP-конфигурации. Вернитесь в LDAP settings. Укажите:
- Group name attribute: Для AD это обычно cn.
- Group member attribute: Для AD — member.
- Group filter: Можете оставить пустым или задать фильтр для поиска только нужных групп, например: (objectClass=group).
Добавьте сопоставление. В разделе Group mapping нажмите Add. В поле LDAP group pattern введите точное имя группы из LDAP (например, IT-Admins). В выпадающем списке User group выберите соответствующую группу Zabbix, созданную на шаге 1.

Теперь, когда пользователь из LDAP-группы IT-Admins войдет в Zabbix, он автоматически попадет в группу Zabbix IT-Admins и получит все назначенные ей права.

Полное тестирование подключения: от поиска пользователя до входа

Не ограничивайтесь одной кнопкой «Test». Проведите комплексную проверку.

Чек-лист тестирования:

Тест аутентификации в настройках. Используйте кнопку «Test authentication» для разных тестовых пользователей.
Попытка реального входа. Откройте приватное окно браузера (чтобы не мешала текущая сессия) и попробуйте войти в веб-интерфейс Zabbix, используя логин и пароль тестового пользователя LDAP. Убедитесь, что вход успешен.
Проверка прав. После входа проверьте, что пользователь видит ожидаемые данные (хосты, дашборды) и имеет соответствующие права (может настраивать триггеры, отключать хосты и т.д., в зависимости от роли).
Анализ логов. В случае неудачи немедленно проверьте логи. Основные файлы:
- /var/log/zabbix/zabbix_web.log — логи frontend.
- /var/log/zabbix/zabbix_server.log — логи сервера.

Для увеличения детализации логов можно временно повысить уровень отладки в /etc/zabbix/zabbix_server.conf, установив DebugLevel=4, и перезапустить сервер. Но не забудьте вернуть значение обратно после отладки.

План финального переключения и отключения локальных аккаунтов

Когда LDAP-аутентификация полностью протестирована и работает параллельно с локальной, можно приступать к финальному переключению. Ключевая стратегия — поэтапность, а не «big bang».

Поэтапное переключение пользователей: стратегия «пилотная группа -> все»

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

Выберите пилотную группу. Это должны быть 2-3 технически подкованных администратора, которые понимают процесс и смогут оперативно дать обратную связь.
Отключите их локальные аккаунты. Для выбранных пользователей в Administration → Users найдите их локальные учетные записи (с таким же логином, как в LDAP) и либо установите флаг Disabled, либо удалите их (если уверены, что LDAP-дубль работает). Рекомендуется сначала отключать, а удалять — только после успешного завершения всей миграции.
Контрольный период. Убедитесь, что пилоты успешно работают через LDAP в течение оговоренного периода (минимум 2-3 дня, лучше неделя). Проверяйте все функции: просмотр, настройка, работа API, получение оповещений.
Массовое отключение. Только после успешного пилота приступайте к отключению локальных аккаунтов для остальных пользователей. Это можно сделать массово SQL-запросом (с крайней осторожностью и при наличии резервной копии!), но надежнее — через веб-интерфейс, выбрав несколько пользователей за раз.

Контрольный список после миграции и процедура отката

После отключения локальных аккаунтов выполните финальные проверки и убедитесь, что процедура отката готова к выполнению.

Чек-лист завершения миграции:

Вход в систему для пользователей из разных LDAP-групп (администраторы, обычные пользователи, гости).
Проверка работы оповещений: триггеры срабатывают, уведомления отправляются на email/мессенджеры, указанные в профилях LDAP-пользователей.
Проверка доступа через Zabbix API, если он используется в ваших скриптах или интеграциях.
Проверка, что аварийная учетная запись zbx_fallback_admin по-прежнему активна и имеет доступ.

Процедура отката (если что-то пошло не так):

Войдите в Zabbix, используя аварийную учетную запись zbx_fallback_admin.
В Administration → Authentication переключите метод аутентификации обратно на Internal.
Восстановите локальных пользователей из резервной копии БД. Можно восстановить только таблицы, связанные с пользователями и группами:
```
# Для MySQL. Будьте осторожны, это перезапишет текущие данные!
mysql -u [user] -p[password] zabbix < <(awk '/INSERT INTO `users`/,/;/' zabbix_backup.sql)
mysql -u [user] -p[password] zabbix < <(awk '/INSERT INTO `usrgrp`/,/;/' zabbix_backup.sql)
# ... и другие связанные таблицы (users_groups, etc.)
```
Лучше иметь готовый скрипт восстановления, протестированный на тестовом стенде.

Решение частых проблем и углубление в детали (Best Practices)

Отладка неудачной аутентификации: читаем логи Zabbix

Умение читать логи — ключ к самостоятельному решению проблем. Вот расшифровка типичных ошибок.

«Invalid credentials» или «Login name or password is incorrect». Чаще всего означает, что пользователь с таким логином не найден в указанном Base DN или неверен пароль. Проверьте Search attribute и правильность написания логина.
«LDAP bind failed». Проблема с подключением сервисной учетной записи (Bind DN). Проверьте правильность DN и пароля, а также доступность сервера по указанному порту. Убедитесь, что учетная запись не заблокирована и имеет права на чтение.
«User is not a member of any group» или пользователь вошел, но не имеет прав. Ошибка в настройке маппинга групп. Проверьте, что имя группы в LDAP (LDAP group pattern) введено точно, включая регистр для некоторых LDAP-серверов. Проверьте атрибуты Group name attribute и Group member attribute.
Ошибки SSL/TLS. «TLS handshake failed». Частая проблема при использовании самоподписанных сертификатов на LDAP-сервере. Вам нужно либо импортировать корневой сертификат ЦС в систему доверия на хосте Zabbix, либо в конфигурационном файле веб-сервера PHP (например, /etc/php/.../php.ini) добавить строку ldap.conf с указанием пути к сертификату, либо временно отключить проверку сертификата (НЕ рекомендуется для production).

Для глубокой отладки можно включить логирование LDAP-запросов на стороне LDAP-сервера (например, в Active Directory — увеличить уровень диагностики для LDAP Interface).

Особенности для Zabbix 6.0 LTS и 7.0: на что обратить внимание

Представленная инструкция полностью актуальна для Zabbix 6.0 LTS и 7.0. Архитектура аутентификации и основные параметры настройки в этих версиях не менялись.

Незначительные отличия, на которые стоит обратить внимание:

В Zabbix 7.0 может быть незначительно обновлен интерфейс раздела LDAP settings, но названия полей и их логика остались прежними.
В Zabbix 7.0 появились новые системные роли (например, «Admin» имеет немного урезанные права по сравнению с «Super admin»). Уделите особое внимание назначению ролей создаваемым группам Zabbix при маппинге.
Всегда сверяйтесь с официальной документацией Zabbix для вашей конкретной мажорной версии, если столкнетесь с неочевидным поведением. Документация по LDAP для Zabbix 6.0/7.0 остается основным источником актуальной информации.

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