# Open WebUI с LDAP или SSO: вход сотрудников и проверка прав

Источник: https://modelium.tech/zhurnal/open-webui-ldap-sso/

Для корпоративного Open WebUI выберите один проверенный путь входа: LDAP с каталогом пользователей либо SSO через OIDC-провайдера. После входа отдельно назначьте системную роль, группы и доступ к конкретной модели; успешная аутентификация не доказывает изоляцию документов. Проверьте разрешённый и запрещённый доступ под двумя тестовыми аккаунтами до подключения реальных данных.

**Проверено по документации 25 сентября 2026 года**, ревизия Open WebUI Docs `c15ca0e`. Это сценарий для тестового контура, не результат внедрения: Modelium не подключал LDAP/SSO, не проверял реальные права и не запускал модель. Подсказка Google подтверждает формулировку запроса, а не его частотность.

## Когда нужен LDAP, а когда SSO?

Если организация уже использует каталог LDAP и хочет проверять учётные данные через него, начните с LDAP-конфигурации Open WebUI [s1](#src-s1). Если сотрудники входят через корпоративного поставщика идентификации по OpenID Connect (OIDC), настройте SSO: Open WebUI поддерживает вход через OIDC без LDAP [s2](#src-s2) [s7](#src-s7). Это **альтернативные маршруты для пилота**, а не обязательная последовательность «сначала LDAP, затем SSO». Trusted Header за прокси — третий, более чувствительный к настройке доверенной границы маршрут; в нём прокси должен удалять присланные клиентом заголовки и вставлять собственные [s2](#src-s2) [s5](#src-s5). Его здесь не настраиваем.

Результат пилота: два заранее созданных тестовых сотрудника входят через выбранный маршрут; одному выдано чтение тестовой модели, второму — нет. Авторизация в интерфейсе и права на конкретную модель — разные проверки [s3](#src-s3) [s4](#src-s4). Вход не доказывает права на отдельные фрагменты документов, корректность ответов модели или отсутствие облачных соединений. Не загружайте персональные данные до собственного теста доступа и сети.

## Что подготовить перед настройкой?

Поднимите Open WebUI на **проверенной вашей командой версии** с отдельным сохраняемым томом `/app/backend/data` и стабильным `WEBUI_SECRET_KEY`, как описано в руководстве Docker; не публикуйте пароль, ключ сессий или client secret в примере, репозитории и shell history [s6](#src-s6) [s5](#src-s5). Сначала проверьте, что локальный runtime отвечает через интерфейс: страница установки Open WebUI описывает подключение Ollama как отдельного endpoint, а сама веб-оболочка не заменяет inference-сервер [s6](#src-s6). Выберите **одну конкретную модель**, доступную обоим тестовым пользователям только после выдачи grant, и зафиксируйте её тег/версию и адрес локального runtime.

Для корпоративной сети заранее определите URL веб-интерфейса, TLS на обратном прокси, сетевую границу/VPN и администратора начальной установки: руководство hardening описывает прокси как точку HTTPS и рекомендует ограничивать доступ к экземпляру [s5](#src-s5). Для OIDC отдельно понадобятся контролируемый IdP, клиент, разрешённый redirect URI и возможность хранить secret вне текста статьи [s2](#src-s2). Для LDAP понадобятся адрес сервера, база поиска, атрибуты пользователя и права bind-учётки [s1](#src-s1). Если корпоративная политика запрещает обращение к внешнему IdP, это нужно проверять отдельно: «локальная модель» не означает «вся аутентификация офлайн».

## Как настроить LDAP без открытого пароля?

Выберите в **Admin Panel → Settings → Authentication → LDAP** уже работающего тестового экземпляра и укажите параметры своего каталога. Документация перечисляет `ENABLE_LDAP`, `LDAP_SERVER_HOST`, `LDAP_SERVER_PORT`, `LDAP_APP_DN`, `LDAP_APP_PASSWORD`, `LDAP_SEARCH_BASE`, `LDAP_ATTRIBUTE_FOR_USERNAME` и `LDAP_ATTRIBUTE_FOR_MAIL`; сервер и атрибуты нужно взять у администратора каталога, а пароль передать через принятый в вашей инфраструктуре механизм секретов [s1](#src-s1). Не копируйте демонстрационные `admin` и `localhost` как production-значения.

Для передачи LDAP-учётных данных рекомендуемая конфигурация hardening — LDAPS с `LDAP_USE_TLS=true`, `LDAP_VALIDATE_CERT=true` и доверенным CA [s5](#src-s5). В LDAP-гайде указаны порт 636 для LDAPS, различие между TLS и простым портом 389, а также **отсутствие StartTLS** у этого переключателя [s1](#src-s1). В тесте проверьте сертификат, а не отключайте проверку ради прохождения входа. `LDAP_SEARCH_FILTER` может дополнительно фильтровать разрешённую группу, но не является заменой прав на ресурсы внутри Open WebUI [s1](#src-s1) [s4](#src-s4).

При первом запуске переменные LDAP считываются в конфигурацию; на уже созданном экземпляре последующие изменения вносите через админ-панель, если только сознательно не отключён persistent config [s1](#src-s1). Откройте отдельное окно браузера и войдите тестовой учёткой: новый пользователь получает роль по текущей политике экземпляра; default `pending` требует одобрения администратора [s1](#src-s1) [s3](#src-s3). Если вход не проходит, проверьте отдельно разрешение имени и порт, сертификат и bind-креденшелы; серверное сообщение `err=49` в гайде означает отказ LDAP по учётным данным, не проблему с моделью [s1](#src-s1). Не вставляйте реальные пароли в опубликованные команды диагностики.

## Как настроить SSO/OIDC вместо LDAP?

Для тестового OIDC-клиента укажите `OPENID_PROVIDER_URL` (адрес discovery), `OAUTH_CLIENT_ID`, `OAUTH_CLIENT_SECRET` и `WEBUI_URL`; на стороне IdP зарегистрируйте точный `<адрес-webui>/oauth/oidc/callback` или соответствующий явно заданный `OPENID_REDIRECT_URI` [s2](#src-s2). Проверьте наличие `email` claim и доступность discovery из контейнера, не подставляя несуществующие переменные вроде `OIDC_CONFIG` [s2](#src-s2). `ENABLE_OAUTH_SIGNUP` отвечает за создание аккаунта после OAuth-входа отдельно от `ENABLE_SIGNUP`; выбирайте его и стартовую роль по политике пилота, а не автоматически разрешайте любого сотрудника IdP [s2](#src-s2) [s3](#src-s3).

На ревизии документации OAuth-настройки **по умолчанию читаются из environment**: при `ENABLE_OAUTH_PERSISTENT_CONFIG=false` раздел OAuth в админ-панели только для чтения; при изменении env перезапустите приложение. Чтобы управлять настройками из панели и сохранять их в базе, нужны `ENABLE_OAUTH_PERSISTENT_CONFIG=true` и включённый `ENABLE_PERSISTENT_CONFIG` [s2](#src-s2). Стабильный `WEBUI_SECRET_KEY` требуется для сессий, особенно если реплик больше одной [s2](#src-s2) [s5](#src-s5). Не включайте `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` без отдельного решения о доверии к подтверждению email у IdP: документация отмечает риск ошибочного связывания аккаунтов [s2](#src-s2).

Только **после успешного входа администратора и тестового пользователя через OIDC** можно отключать локальный экран входа (`ENABLE_LOGIN_FORM=false`) и, если нужен полностью SSO-only путь, серверную password-аутентификацию (`ENABLE_PASSWORD_AUTH=false`); сохраните согласованный аварийный порядок доступа до переключения [s5](#src-s5) [s7](#src-s7). Для SSO-only не требуется включать LDAP. При ошибке `redirect_uri` сначала сравните URL запроса и запись клиента в IdP, а не отключайте безопасность [s2](#src-s2).

## Как разделить две роли и доступ к модели?

Системные роли Open WebUI — `admin`, `user`, `pending`; `admin` по умолчанию имеет широкие полномочия, `pending` не получает рабочий доступ [s3](#src-s3). Для проверки возьмите **двух обычных пользователей **`**user**`, а не администратора как «положительный» тест: его стандартный обход ACL исказит результат [s3](#src-s3) [s4](#src-s4). Создайте тестовые группы «Пилот» и «Контроль» в Admin Panel → Users → Groups; дайте только «Пилоту» право чтения **Private** тестовой модели. Для группы «Контроль» не выдавайте этот grant, не оставляйте wildcard/Public и убедитесь, что у сотрудника нет другой группы или прямого grant на ту же модель [s4](#src-s4).

Права групп **аддитивны**: запрет в одной группе не отменяет grant другой; отсутствие deny-групп важно при разборе неожиданного доступа [s4](#src-s4). Отдельно различайте право пользоваться функцией (например, Knowledge Access) и grant на конкретную модель или knowledge base: это разные слои [s8](#src-s8) [s4](#src-s4). Включение SSO само не включает документный ACL. Если используете OIDC group claims, `ENABLE_OAUTH_GROUP_MANAGEMENT` синхронизирует членство при входе и может удалить локально назначенные группы, которых нет в непустом claim; перед включением проверьте состав claims [s2](#src-s2). Для LDAP-пилота назначьте группы вручную и проверьте их в Open WebUI; не предполагайте, что LDAP-группа автоматически стала группой доступа к модели [s1](#src-s1) [s4](#src-s4).

## Каким тестом подтвердить результат и границы?

- В пустом профиле браузера войдите аккаунтом «Пилот». Убедитесь, что выданы роль `user`, группа «Пилот», доступ к одной тестовой модели и ответ на **безличный** контрольный запрос. Зафиксируйте модель, runtime, версию Open WebUI, путь входа и результат — это собственный протокол пилота, а не тест Modelium.

- В другом профиле войдите аккаунтом «Контроль» той же системной роли. Проверьте отсутствие тестовой модели в интерфейсе **и отказ при прямом обращении к ней через API**, если у вашей установки есть авторизованный тестовый способ такого обращения. Admin-only **Preview Access** показывает итоговые grants модели/knowledge/tool для пользователя; используйте его для аудита, но не вместо отрицательного запроса [s4](#src-s4).

- Снимите grant у первого пользователя или переведите его в `pending`, повторите проверку с уже открытой вкладкой и с новым запросом. В документации роль `pending` отказывает в запросах, изменения роли пересматриваются для REST; group grant и роль проверяйте как разные события [s3](#src-s3) [s4](#src-s4).

- Если для модели прикреплена база знаний, отдельно проверьте доступ к **Private** knowledge base и проверяемость ответа на тестовые документы под обоими аккаунтами. Документация отличает scoping прикреплённых баз от видимости ресурса; тест одной модели не подтверждает фильтрацию документов внутри общей коллекции [s4](#src-s4). Для документов со смешанными правами нужен отдельный пилот поиска на уровне документа.

Если «Контроль» видит модель, разберите Public/wildcard grant, другие группы, прямой grant и системную роль прежде, чем менять LDAP/SSO [s4](#src-s4). Если пользователь входит, но не видит ничего, проверьте `pending`, выбранную модель/runtime и права на функции; сбой входа и сбой прав — разные причины [s3](#src-s3) [s8](#src-s8). Если после выхода сеанс остаётся пригодным, проверьте политику JWT/Redis: руководство hardening прямо предупреждает, что без Redis выход не аннулирует токен до истечения, хотя изменение роли пересматривается на запросе [s5](#src-s5) [s3](#src-s3). Не утверждайте, что один успешный тест доказывает безопасность всей установки.

## Как откатить пилот и что делать дальше?

Снимите тестовые grants, удалите ненужные тестовые аккаунты/группы по регламенту, отмените тестовый OIDC-клиент или LDAP bind-учётку и убедитесь, что администратор сохранил рабочий вход. Не меняйте `WEBUI_SECRET_KEY` как обычную чистку: его замена завершит существующие сессии [s5](#src-s5). Экземпляр с настоящими разговорами и файлами не удаляйте вместе с volume `/app/backend/data`, пока не выполнены резервное копирование и политика хранения [s6](#src-s6).

**Основной следующий шаг:** [подготовить Open WebUI и локальный runtime](/zhurnal/open-webui/), проверить контрольный ответ модели и только затем повторить описанный тест под двумя аккаунтами. Для полностью закрытого контура отдельно проверьте сетевые вызовы: сам факт входа по LDAP/SSO не доказывает отсутствие внешних подключений.

## Источники

1. [Open WebUI Docs — LDAP Authentication](https://raw.githubusercontent.com/open-webui/docs/c15ca0e0ee8a1cd541a3fddcc86e3a630ce80464/docs/features/authentication-access/auth/ldap.mdx) — получено 2026-09-25
2. [Open WebUI Docs — SSO (OAuth, OIDC, Trusted Header)](https://raw.githubusercontent.com/open-webui/docs/c15ca0e0ee8a1cd541a3fddcc86e3a630ce80464/docs/features/authentication-access/auth/sso/index.mdx) — получено 2026-09-25
3. [Open WebUI Docs — Roles](https://raw.githubusercontent.com/open-webui/docs/c15ca0e0ee8a1cd541a3fddcc86e3a630ce80464/docs/features/authentication-access/rbac/roles.md) — получено 2026-09-25
4. [Open WebUI Docs — Groups and Resource Access](https://raw.githubusercontent.com/open-webui/docs/c15ca0e0ee8a1cd541a3fddcc86e3a630ce80464/docs/features/authentication-access/rbac/groups.md) — получено 2026-09-25
5. [Open WebUI Docs — Hardening Open WebUI](https://raw.githubusercontent.com/open-webui/docs/c15ca0e0ee8a1cd541a3fddcc86e3a630ce80464/docs/getting-started/advanced-topics/hardening.md) — получено 2026-09-25
6. [Open WebUI Docs — Manual Docker Setup](https://raw.githubusercontent.com/open-webui/docs/c15ca0e0ee8a1cd541a3fddcc86e3a630ce80464/docs/getting-started/quick-start/tab-docker/ManualDocker.md) — получено 2026-09-25
7. [Open WebUI Docs — Authentication and Access Control Overview](https://raw.githubusercontent.com/open-webui/docs/c15ca0e0ee8a1cd541a3fddcc86e3a630ce80464/docs/features/authentication-access/index.mdx) — получено 2026-09-25
8. [Open WebUI Docs — Permissions](https://raw.githubusercontent.com/open-webui/docs/c15ca0e0ee8a1cd541a3fddcc86e3a630ce80464/docs/features/authentication-access/rbac/permissions.md) — получено 2026-09-25