Пользователи и роли

В GetOLT две схемы аутентификации, которые можно сочетать или использовать по отдельности:

Локальный администратор — на старте, для self-hosted установки.
LDAP / Active Directory — для корпоративных операторов, где у сотрудников уже есть учётные записи в доменной службе.

UI создания дополнительных локальных пользователей в текущей версии не реализован — для расширения круга доступов используется LDAP/AD. Если корпоративного каталога нет, напишите в support@getolt.online — UI пользователей в дорожной карте.

Локальный администратор

Первый запуск GetOLT создаёт встроенную учётную запись admin. Логин и пароль задаются через переменные окружения в /opt/getolt/.env:

GETOLT_ADMIN_USERNAME=admin
GETOLT_ADMIN_PASSWORD=<сгенерированный пароль>

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

LDAP / Active Directory

После того как корпоративный каталог настроен и сотрудники могут авторизовываться по своим логинам, локальная учётная запись остаётся как fallback на случай, если LDAP-сервер недоступен.

Параметры подключения

GetOLT использует стандартный Spring Security LDAP — конфигурация ведётся через переменные окружения. Минимальный набор:

# Включить LDAP
LDAP_ENABLED=true

# URL LDAP-сервера: ldap://host:389 или ldaps://host:636 (TLS)
LDAP_URL=ldap://dc.company.local:389

# Корень каталога (Base DN)
LDAP_BASE=DC=company,DC=local

# Фильтр поиска пользователя по введённому логину
# Active Directory:
LDAP_USER_SEARCH_FILTER=(sAMAccountName={0})
# OpenLDAP:
# LDAP_USER_SEARCH_FILTER=(uid={0})

# Сервис-аккаунт для bind (read-only прав достаточно).
# Active Directory принимает два формата — выберите один:
#   1) Полный Distinguished Name (каноничный LDAP-формат):
LDAP_MANAGER_DN=CN=svc_getolt,CN=Users,DC=company,DC=local
#      — путь до сервис-аккаунта в каталоге. CN=Users — папка по умолчанию,
#      где AD кладёт юзеров если их не вынесли в отдельный OU. Если ваш
#      сервис-аккаунт лежит в OU=Service Accounts — заменить на
#      CN=svc_getolt,OU=Service Accounts,DC=company,DC=local.
#   2) User Principal Name (короткая форма, работает только в Active Directory):
#LDAP_MANAGER_DN=svc_getolt@company.local
#      — то же что юзер вбивает в Outlook/RDP. Удобнее, но в OpenLDAP не работает.

LDAP_MANAGER_PASSWORD=<пароль сервис-аккаунта>

# Опционально: сузить поиск конкретным OU (пусто = искать от LDAP_BASE рекурсивно).
# В типовом AD оставлять пустым — поиск от корня домена находит всех нужных юзеров.
LDAP_USER_SEARCH_BASE=

# Опционально: выключить локальный admin, когда LDAP заработал
# (admin/<env-пароль> остаётся доступен пока эта строка закомментирована).
#SECURITY_LOCAL_USERS_ENABLED=false

LDAP_USER_SEARCH_BASE нужен только если юзеры в AD лежат в конкретном OU (например OU=Employees,OU=Company) и хочется не сканировать service accounts / computer objects в других OU. Для большинства инсталляций — оставлять пустым.

Как применить изменения `.env`

После правки /opt/getolt/.env контейнер нужно пересоздать, а не просто перезапустить:

cd /opt/getolt
docker compose up -d --force-recreate app

docker compose restart app не перечитает новые переменные — он рестартит процесс в том же контейнере с прежним окружением.
--force-recreate пересоздаёт контейнер с актуальным .env, данные MySQL и лицензия (./data, ./license) не затрагиваются — они на томах.

Проверить, что переменные реально дошли до приложения:

docker compose exec app env | grep ^LDAP_

Должны вывестись все строки LDAP_*, которые вы прописали в .env. Если выводится только LDAP_ENABLED — обновите docker-compose.yml из дистрибутива (curl -fsSL https://get.getolt.online/docker-compose.client.yml -o docker-compose.yml) и повторите команду.

Что нужно подготовить на стороне Active Directory

Сервис-аккаунт (svc_getolt или любой другой) с правами на чтение каталога — без админских привилегий. Пароль не должен меняться по политике безопасности или должен ротироваться согласованно с обновлением .env.

Три группы доступа — GetOLT назначает роли по членству юзера в одной из трёх AD-групп. Имена групп зафиксированы в коде и должны совпадать буква в букву (case-insensitive, латиница):

Группа в AD	Роль в GetOLT	Что может
`GetOLT_Admins`	`ROLE_ADMIN`	Всё: управление OLT, пользователи, настройки, биллинг-интеграции
`GetOLT_Users`	`ROLE_USER`	Просмотр OLT/ONU, поиск абонентов, базовые операции
`GetOLT_Operators`	`ROLE_OPERATOR`	Операции с ONU (рестарт, прошивка, перепривязка) — для службы техподдержки

Сотрудника достаточно добавить в одну из этих групп. Юзер, не входящий ни в одну из трёх, залогинится, но не получит ролей — функции GetOLT, требующие конкретную роль, ему будут недоступны. Это типичная причина «вход прошёл, но интерфейс пустой / “доступ запрещён”».

Сетевая связность от хоста GetOLT до контроллера домена по портам:
- 389/tcp для LDAP
- 636/tcp для LDAPS (рекомендуется в проде)

Создание групп через PowerShell

На контроллере домена (или любом хосте с RSAT) от имени Domain Admin:

# Создать три группы в OU=Groups (поправьте OU под свою структуру)
New-ADGroup -Name "GetOLT_Admins"    -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=company,DC=local"
New-ADGroup -Name "GetOLT_Users"     -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=company,DC=local"
New-ADGroup -Name "GetOLT_Operators" -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=company,DC=local"

# Добавить сотрудника (sAMAccountName = ivanov) в нужную группу
Add-ADGroupMember -Identity "GetOLT_Admins" -Members "ivanov"
Add-ADGroupMember -Identity "GetOLT_Users"  -Members "petrov","sidorov"

После добавления юзеру нужно перезайти в GetOLT — Spring Security читает memberOf при логине, не пересчитывает на каждый запрос.

Проверка подключения

После выставления переменных окружения и перезапуска контейнера:

Откройте /login.
Введите доменный логин (без указания домена, например ivanov) и пароль.
Если в логах видно Successfully authenticated user: ivanov — LDAP отдаёт пользователя, доступ есть.
Если LDAP authentication failed — типовые причины:
- Неверный LDAP_MANAGER_DN или его пароль.
- Сетевая недоступность контроллера домена.
- Реально неверный пароль самого пользователя в форме /login.
Если вход прошёл, но интерфейс пустой или “доступ запрещён” на нужных разделах — юзер залогинился, но не получил роль: не добавлен ни в GetOLT_Admins, ни в GetOLT_Users, ни в GetOLT_Operators. См. раздел Что нужно подготовить на стороне Active Directory — это самая частая причина «настроил LDAP, юзер входит, но ничего не работает».

Расшифровка ошибок Active Directory (`error code 49 - 80090308`)

В тексте ошибки AD возвращает sub-код data XXX, который точно говорит где именно сломалось — это полезнее, чем общий «LDAP authentication failed»:

Код	Что значит	Что проверять
`525`	User not found	`LDAP_BASE`, `LDAP_USER_SEARCH_FILTER` — юзер не нашёлся в указанном поддереве. Проверить что вводят `sAMAccountName` без домена (например `ivanov`, а не `ivanov@company.local`).
`52e`	Invalid credentials	Юзер найден, но пароль не совпал. Caps Lock / раскладка / в AD недавно сменили пароль. Если это пароль сервис-аккаунта (`LDAP_MANAGER_PASSWORD`) — проверить его отдельно через `ldapsearch` с того же хоста.
`530`	Not permitted to logon at this time	В AD у юзера ограничены часы входа.
`531`	Not permitted to logon at this workstation	В AD у юзера ограничен список рабочих станций — добавить хост GetOLT в разрешённые или снять ограничение.
`532`	Password expired	Юзер должен сменить пароль через стандартные средства AD.
`533`	Account disabled	Включить аккаунт в AD.
`701`	Account expired	Продлить срок действия аккаунта.
`773`	User must reset password	Юзер должен сменить пароль при следующем входе — пока не сменит, LDAP-bind будет фейлиться.
`775`	Account locked out	Разблокировать (`net user <username> /domain /active:yes` или через AD Users and Computers).

Если в логах data 52e для обычного юзера — конфигурация LDAP правильная (до AD достучались, юзера нашли), проблема в его пароле. Если data 52e для сервис-аккаунта — неверный LDAP_MANAGER_PASSWORD в .env.

Раздел «Админка» и доступ по ролям

Служебные разделы GetOLT — Планировщики (фоновые задачи опроса и синхронизации), Обогащение ONU, API-ключи и Лицензия — собраны в один раздел «Админка». Он открывается из выпадающего меню профиля в правом верхнем углу: слева — меню разделов, справа — содержимое выбранного.

По умолчанию вся «Админка» доступна только роли ROLE_ADMIN. Исключение — страница Лицензия: её просмотр открыт любому авторизованному пользователю (это информер о состоянии лицензии, тот же, что по клику на плашку в шапке). Замена файла лицензии доступна только администратору.

Чтобы открыть служебные разделы не только администраторам (например, технической службе с ролью ROLE_OPERATOR), перечислите роли в переменной окружения — через запятую, без префикса ROLE_:

# По умолчанию — только ADMIN. Пример: добавить операторов.
ADMIN_AREA_ROLES=ADMIN,OPERATOR

После правки /opt/getolt/.env пересоздайте контейнер (docker compose up -d --force-recreate app) — как описано в разделе Как применить изменения .env.

Сочетание локального admin и LDAP

Локальный admin остаётся всегда — это аварийный канал на случай проблем с доменом (упал контроллер, истёк пароль сервис-аккаунта, разорвалась VPN до AD). Для повседневной работы команды используют LDAP.

Если нужны более сложные политики — 2FA, отдельные роли для техподдержки и инженерной службы, ограничение по подсетям — напишите в support@getolt.online или в Telegram @getolt_pub: эти сценарии в дорожной карте и приоритизируются под запросы первых пилотных клиентов.

Нашли ошибку или нужно что-то дополнить? Напишите нам или в Telegram @getolt_pub.

Разработка: gmasich.ru

Политика конфиденциальности · Пользовательское соглашение