4. Интеграция с LDAP

Интеграция с LDAP

В этой главе — про вход через корпоративный каталог (LDAP / Active Directory) и про то, как Accelera решает, какую роль выдать LDAP-пользователю.

Как работает вход через LDAP

1. Пользователь вводит в форму логина свой корпоративный логин и пароль.
2. Accelera пытается аутентифицировать его в LDAP.
3. Если аутентификация прошла — Accelera запрашивает список групп, в которых состоит этот пользователь (через атрибут memberOf в Active Directory или через поиск по member в OpenLDAP).
4. Из этих групп выбирается первая, для которой найдено сопоставление с ролью Accelera.
5. Пользователю выдаётся соответствующая роль и создаётся (или обновляется) запись в локальной таблице пользователей.

Локальный пароль такому пользователю не сохраняется — следующий вход опять пойдёт через LDAP.

Как настраивается соответствие «LDAP-группа → роль»

В Accelera 4.0.0 соответствие хранится в поле **ldap_group** у каждой роли (через UI: Администрирование → Роли → Редактировать роли). Если пользователь состоит в группе с таким именем — он получит эту роль.

Поиск идёт по точному совпадению имени группы. Регистр и пробелы должны совпадать с тем, что отдаёт LDAP-сервер.

Дефолтные значения после установки

В большинстве клиентских инсталляций корпоративные группы называются по-другому (например, Marketing-Admins, CIB-Analysts). После установки обязательно замените значения ldap_group на реальные имена групп клиента.

Fallback: env-переменные

Если у роли поле ldap_group пустое или не нашлось ни одной подходящей роли — Accelera пробует резервный механизм через переменные окружения:

LDAP_ADMIN_ROLE=AcceleraAdmins
LDAP_USER_ROLE=AcceleraUsers
LDAP_READONLY_ROLE=AcceleraReadOnly
LDAP_SCREENS_USER_ROLE=AcceleraScreensUser
LDAP_SCREENS_READ_ONLY_ROLE=AcceleraScreensReadOnly
LDAP_SCREENS_MAKER_ROLE=AcceleraScreensMaker

Эти переменные задаются в конфигурации деплоя (.env-файле или через переменные окружения сервиса). Менять их через UI нельзя.

Рекомендация: настраивайте сопоставления через UI (поле ldap_group), а env-переменные используйте только как страховку.

Что нужно сделать после обновления (чек-лист)

После обновления на 4.0.0 LDAP-вход работает не сразу — нужны три шага:

1. Узнать у IT-администратора клиента имена корпоративных групп, которые соответствуют ролям Accelera.
2. Открыть Администрирование → Роли → Редактировать роли и в каждой роли заменить значение LDAP группа на реальное имя.
3. Проверить вход одним из тестовых LDAP-пользователей. Если в системе он не появлялся раньше — после первого успешного входа он появится в списке Пользователей со статусом LDAP (см. главу 2 «Управление пользователями», раздел «Типы пользователей: локальные и LDAP»).

OpenLDAP vs Active Directory

Accelera 4.0.0 поддерживает оба варианта.

• Active Directory (большинство корпоративных установок): используется атрибут memberOf — сервер сам отдаёт список групп пользователя при аутентификации. Никаких дополнительных настроек обычно не нужно.

• OpenLDAP: если на сервере установлен overlay memberof — поведение такое же, как у AD. Если overlay не установлен (это типично для старых OpenLDAP) — Accelera сама обходит группы поиском по атрибуту member. Для этого нужно задать переменную окружения:

  LDAP_GROUPS_BASE=ou=Groups,dc=example,dc=com

  Это базовый DN, в котором лежат группы. Уточните у IT-администратора клиента.

Типичные проблемы

LDAP-пользователь не может войти

Проверьте по порядку:

1. Сервис вообще видит LDAP? В логах backoffice при попытке входа должны быть сообщения о подключении к LDAP. Если их нет — проверьте сетевую связность и переменные LDAP_URL, LDAP_BIND_DN, LDAP_BIND_PASSWORD.
2. Аутентификация прошла, но роль не выдана? Убедитесь, что хотя бы для одной роли поле ldap_group совпадает с реальной группой пользователя. Список групп пользователя можно посмотреть на стороне LDAP (ldapsearch или AD-консоль).
3. OpenLDAP без **memberof**? Установите LDAP_GROUPS_BASE (см. выше).

LDAP-пользователь получает не ту роль

Если пользователь состоит в нескольких группах, и каждой из них соответствует своя роль Accelera, берётся та, которая встретилась первой при обходе. Чтобы избежать неоднозначности:

• Не назначайте одну и ту же ldap_group нескольким ролям.
• Не давайте одному корпоративному пользователю несколько LDAP-групп, привязанных к разным ролям.

LDAP-пользователь после смены группы видит старые права

Права кэшируются на 5 минут. Либо подождите, либо сделайте пользователю logout/login — кэш сбросится.

Локальные пользователи параллельно с LDAP

LDAP не отменяет локальных пользователей. Можно одновременно:

• иметь несколько локальных учёток (например, технический admin для аварийных случаев);
• разрешать LDAP-вход всем сотрудникам клиента.

При попытке входа Accelera сначала ищет пользователя в локальной таблице, и только если его там нет — идёт в LDAP.

Рекомендация безопасности: заведите хотя бы одного локального admin-пользователя со сложным паролем и храните его в безопасном месте. Это спасёт, если LDAP-сервер будет недоступен или у роли admin слетит привязка к LDAP-группе.

Приложение А. Обновление с 3.3.42 на 4.0.0

Если вы уже работаете с 4.0.0 и не помните 3.3.42 — этот раздел можно пропустить.

Ключевые отличия и риски при обновлении:

1. Маппинг LDAP-групп переехал в БД. В 3.3.42 это были только env-переменные LDAP_ADMIN_ROLE, LDAP_USER_ROLE. После обновления старые значения остаются как fallback, но основной источник — поле ldap_group у роли. Действие: после обновления зайдите в Роли → Редактировать роли и проверьте, что ldap_group заполнен правильно для каждой роли.

2. Роль **read-only** переименована в **readonly**. Если в БД есть пользователи со старой ролью read-only (с дефисом), миграция при обнаружении неизвестной роли назначит им роль user — то есть права повысятся. Действие: перед миграцией выполнить:

   UPDATE users SET role = 'readonly' WHERE role = 'read-only';

   Если таких пользователей нет — пункт можно пропустить.

3. Доступ к endpoint'ам по умолчанию запрещён. В 3.3.42 middleware (isAdmin, isUser) явно пропускали роли. В 4.0.0 endpoint без явного маппинга на право — закрыт. Действие: если у клиента есть кастомные endpoint'ы или плагины — проверьте, что они работают, и при необходимости попросите разработчиков добавить им маппинг прав.

4. Redis обязателен. Права кэшируются в Redis с TTL 5 минут. Без Redis сервис не запустится корректно. Действие: убедиться, что Redis доступен.

Чек-лист перед обновлением

• Сделан бэкап БД.
• Известны корпоративные имена LDAP-групп клиента.
• В таблице users нет записей с ролью read-only (или они переименованы в readonly).
• Redis доступен.
• Имеется хотя бы один локальный admin для аварийного входа.

Что произойдёт автоматически

При запуске новой версии система сама создаст таблицы и роли, заполнит дефолтные ldap_group и переведёт всех существующих пользователей на новую модель. Никаких ручных шагов на стороне БД от администратора не требуется — нужно только выполнить чек-лист выше и после старта проверить настройки LDAP-групп через UI.

← Назад: Глава 3 — Управление ролями и правами

↑ К содержанию руководства