Подключение Jitsi Meet к Active Directory: Полное руководство по настройке и отладке

Jitsi Meet — открытая платформа для видеоконференций. Её можно подключить к Active Directory (AD), чтобы сотрудники входили под корпоративными учётными записями: пользователей не нужно заводить отдельно, а отключение учётной записи в AD сразу закрывает доступ к конференциям.

В руководстве разобрано подключение Jitsi Meet в Docker к AD на Windows Server 2016 и порядок отладки, который помогает быстро найти причину ошибки. Установка Jitsi в Docker описана в статье «Как установить Jitsi Meet на свой сервер с помощью Docker», сравнение с облачными сервисами — в статье «Jitsi Meet против Google Meet». Если вместо AD используется Linux-каталог, см. статью о FreeIPA.

Важно: без шифрования пароли пользователей передаются по сети открытым текстом. Для проверки схемы это допустимо, но в рабочей системе нужен LDAPS (порт 636) с корректным сертификатом — настройка приведена ниже.

Подготовка Active Directory

Нужна отдельная служебная учётная запись (bind-аккаунт), от имени которой Prosody ищет пользователей в каталоге.

1. Создаём bind-аккаунт

1. В консоли Active Directory Users and Computers создайте пользователя, например:

   • Name = bind
   • SamAccountName = binduser

2. Задайте длинный случайный пароль и снимите флаг User must change password at next logon.

3. Через мастер делегирования (Delegate Control) выдайте права «Read all user information» на нужное подразделение (OU).

2. Получаем DN пользователя

На контроллере домена выполните в PowerShell:

Get-ADUser -Identity "binduser" -Properties DistinguishedName

Пример вывода:

CN=bind,CN=Users,DC=example,DC=local

Это значение DistinguishedName понадобится при настройке Jitsi.

3. Временно ослабляем требования к подписи LDAP (только для проверки)

Если при подключении по ldap:// появляется ошибка Strong auth required, контроллер требует подписи LDAP. Для проверки схемы можно временно ослабить требование:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LDAPServerIntegrity" -Value 1
Restart-Service NTDS -Force

Значение 1 означает «подпись по согласованию» (Negotiate signing). После проверки верните значение 2 и переходите на LDAPS: оставлять ослабленную политику на контроллере домена нельзя.

Настройка Jitsi Meet в Docker

В каталоге docker-jitsi-meet добавьте параметры LDAP в файл .env (имена переменных — по env.example проекта):

ENABLE_AUTH=1
AUTH_TYPE=ldap
LDAP_URL=ldap://your-dc.example.com:389/
LDAP_BASE=DC=example,DC=local
LDAP_BINDDN=CN=bind,CN=Users,DC=example,DC=local
LDAP_BINDPW=YourBindPassword
LDAP_FILTER=(sAMAccountName=%u)
LDAP_AUTH_METHOD=bind
LDAP_VERSION=3
LDAP_USE_TLS=0
LDAP_TLS_CHECK_PEER=0
ENABLE_GUESTS=0

Для входа по адресу вида user@domain.local замените фильтр:

LDAP_FILTER=(userPrincipalName=%u)

Вариант для рабочей системы: LDAPS

LDAP_URL=ldaps://your-dc.example.com:636/
LDAP_USE_TLS=1
LDAP_TLS_CHECK_PEER=1
LDAP_TLS_CACERT_FILE=/etc/ssl/certs/ca-certificates.crt

С LDAP_TLS_CHECK_PEER=1 сертификат контроллера проверяется, поэтому корневой сертификат вашего центра сертификации должен быть в хранилище, на которое указывает LDAP_TLS_CACERT_FILE (или LDAP_TLS_CACERT_DIR) внутри контейнера. Вместо LDAPS можно использовать STARTTLS: LDAP_START_TLS=1 с адресом ldap://.

Разрешение имени контроллера: extra_hosts

Контейнер prosody может не разрешать имя контроллера домена, если Docker использует публичные DNS-серверы. В этом случае пропишите адрес контроллера вручную через extra_hosts в docker-compose.yml.

Пример секции:

services:
  prosody:
    image: jitsi/prosody:latest
    extra_hosts:
      - "your-dc.example.com:192.168.1.10"

Перезапустите контейнеры:

docker compose down
docker compose up -d

Проверяем конфигурацию Prosody

Проверьте, что настройки попали в конфигурацию saslauthd внутри контейнера:

docker compose exec prosody bash
cat /etc/saslauthd.conf

Параметры должны совпадать с переменными из .env.

Тестирование и отладка

Прежде чем входить через браузер, проверьте LDAP и SASL из контейнера.

1. Устанавливаем инструменты

apt-get update
apt-get install -y ldap-utils 

2. Проверяем bind-аккаунт

ldapsearch -x -H ldap://your-dc.example.com:389 \
  -D "CN=bind,CN=Users,DC=example,DC=local" \
  -w 'YourBindPassword' \
  -b "DC=example,DC=local" "(sAMAccountName=user)"

Если команда вернула запись пользователя, подключение и поиск работают.

3. Проверяем авторизацию пользователя

testsaslauthd -u user -p 'UserPassword' -s xmpp -r meet.jitsi

Ожидаемый результат:

0: OK "Success."

Проверяем вход через веб-интерфейс

Откройте https://your-jitsi.com и войдите под учётной записью из AD. При успешной настройке пользователь может создавать конференции.

Отладка и диагностика ошибок

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

Проверяем сетевое соединение и доступность AD

Просматриваем логи Prosody

docker compose logs prosody | grep -i "auth\|ldap\|failure"

Для подробной диагностики запустите saslauthd в отладочном режиме:

killall saslauthd
saslauthd -d -a ldap -O /etc/saslauthd.conf -n 5

И повторите проверку:

testsaslauthd -u user -p 'Password' -s xmpp -r meet.jitsi

Типичные ошибки:

• Unknown — неверный DN или фильтр.
• Invalid credentials — ошибка в пароле binduser.
• Bind failed — TLS-проблема или политика безопасности AD.

Проверяем состояние в Active Directory

На контроллере домена проверьте состояние учётной записи:

Get-ADUser user -Properties LockedOut, BadLogonCount, DistinguishedName
Unlock-ADAccount -Identity user

Неудачные попытки входа отображаются в Event Viewer → Windows Logs → Security (события 4625). Если таких событий нет, запрос от Jitsi до контроллера не доходит — проверяйте сеть и адрес в LDAP_URL.

Частые проблемы и их решения

Заключение

Подключение Jitsi Meet к Active Directory переводит вход в конференции на корпоративные учётные записи. Главное — правильно указать DN служебной учётной записи и фильтр поиска и проверить их через ldapsearch и testsaslauthd до входа через браузер. После проверки обязательно включите LDAPS и верните строгие требования к подписи LDAP на контроллере домена.