Linux

Veyon на Ubuntu с авторизацией через Active Directory без ввода Linux в домен

Практический опыт интеграции Veyon Master 4.11.3 на Ubuntu 24.04 с Kerberos, PAM и LDAPS без realm join.

Статус: актуальноОпубликовано: 2026-10-14Обновлено: 2026-10-14

Проверено на: Ubuntu 24.04.5 LTS · Veyon 4.11.3 · Kerberos · PAM · LDAPS

Задача

Требовалось использовать Veyon Master под Ubuntu для удалённого просмотра и управления рабочими станциями Windows. Учётные записи операторов должны проходить проверку через Active Directory, а список рабочих станций — загружаться из каталога. При этом Ubuntu не должна становиться членом домена: без realm join, учётной записи компьютера в AD и полноценного SSSD domain enrollment.

Реальные домены, имена пользователей, контроллеров, OU и IP-адреса обезличены. В примерах используется зарезервированный для документации домен ad.example.com. Показанные конфигурации — адаптируемые примеры, а не дословные копии производственной системы.

Архитектура

Ubuntu 24.04.5 / Veyon Master 4.11.3 (не входит в AD)
        ├── Kerberos + отдельный PAM → контроллеры AD
        ├── LDAPS TCP/636 → пользователи, группы, компьютеры AD
        └── Veyon Master → Veyon Service на Windows
                              ├── Logon authentication
                              └── Access-control rules

Здесь важно различать три механизма: PAM/Kerberos проверяет пользователя, LDAPS предоставляет объекты каталога, а Windows Veyon Service проверяет доступ к удалённому компьютеру. Успешное подключение к LDAP само по себе не даёт оператору права управлять станцией.

1. Проверка DNS, времени и сети

Для Kerberos необходимы корректный DNS, синхронизация времени и доступность контроллеров домена.

resolvectl query dc01.ad.example.com
timedatectl status
nc -vz dc01.ad.example.com 88
nc -vz dc01.ad.example.com 636
nc -vz workstation01.ad.example.com 11100

Порт Veyon Service не следует публиковать в интернет. Доступ к нему ограничивается административными подсетями и политиками безопасности.

2. Kerberos без realm join

Для Ubuntu настраивается Kerberos realm (например, AD.EXAMPLE.COM) с указанием KDC. В реализованной схеме применялся отдельный сервисный principal и защищённый keytab. Это не равнозначно присоединению Linux-компьютера к домену.

Проверка параметров Kerberos выполняется командами:

klist
klist -k -e /path/to/protected.keytab

Путь приведён условно. Keytab — секретный материал, его нельзя публиковать в GitHub или включать в статью. Порядок выпуска, хранения и ротации должен соответствовать политике управления сервисными учётными записями.

3. Отдельный PAM-профиль для Veyon

Вместо изменения /etc/pam.d/login или общесистемных модулей был создан отдельный профиль /etc/pam.d/veyon, использующий pam_krb5. Это ограничивает влияние Veyon на остальные способы входа в Ubuntu.

В конфигураторе Veyon выбирается Logon authentication с именем пользовательского PAM-сервиса veyon.

Проверка:

pamtester veyon demo-operator authenticate acct_mgmt

В пилотном тесте доменный оператор успешно проходил проверки authenticate и acct_mgmt. Отрицательный тест с недоступным keytab завершился отказом. Следовательно, проверка действительно зависела от настроенного Kerberos, а не от случайного совпадения с локальным пользователем.

Конкретные аргументы pam_krb5 зависят от сборки модуля. Их необходимо проверять по установленной версии, а не копировать без адаптации.

4. Проблема veyon-auth-helper

В ходе внедрения обнаружен сбой veyon-auth-helper на пути запуска привилегированного помощника. Проверка затронула пакет, права файла и зависимости. После установки исправленной совместимой сборки аутентификация в Veyon Master заработала.

Это не универсальный рецепт исправления. Привилегированные исполняемые файлы следует обновлять только из проверенного источника; любое локальное изменение требует отдельного аудита и плана отката.

5. Чтение объектов AD через LDAPS

Для LDAP использовалась отдельная непривилегированная учётная запись, предназначенная для чтения каталога. На Ubuntu настраивается доверие к удостоверяющему центру, а подключение выполняется по LDAPS с проверкой сертификата и имени сервера.

Пример проверки каталога:

ldapsearch -x   -H ldaps://dc01.ad.example.com:636   -D 'CN=svc-ldap-reader,CN=Users,DC=ad,DC=example,DC=com'   -W   -b 'OU=Workstations,DC=ad,DC=example,DC=com'   '(objectCategory=computer)' dNSHostName

В настройках Veyon LDAP используются адрес сервера, порт 636, Base DN, сервисная учётная запись, атрибуты sAMAccountName и dNSHostName, а также нужное поддерево компьютеров. В пилоте подтверждено чтение объектов рабочих станций и OU из AD.

6. Авторизация на Windows

Veyon Service на Windows использовал Logon authentication. Ограничение доступа к управлению следует реализовывать отдельной группой операторов Active Directory и правилами Veyon Access Control.

Необходимо проверить два сценария: участник группы может подключиться, а доменный пользователь вне группы получает отказ. Успешное подключение оператора в пилоте было подтверждено. Отрицательный тест с валидной учётной записью вне разрешённой группы пока не зафиксирован как пройденный.

Что проверили

Проверка	Результат
Ubuntu не присоединена к домену	Подтверждено
Kerberos и защищённый keytab	Успешно
Аутентификация через отдельный PAM	Успешно
Негативная проверка с недоступным keytab	Отказ
LDAPS, чтение компьютеров и OU	Успешно
Veyon Master → Windows Veyon Service	Успешно
Просмотр экрана и удалённое управление	Успешно
Запрет доступа пользователю вне AD-группы	Требует отдельной проверки

Небольшие артефакты отображения экрана относились к графической части и не были связаны с проверкой учётных данных.

Диагностика и эксплуатация

При ошибках нужно последовательно проверить DNS и время, KDC, PAM-сервис, сервисную учётную запись, доверие к сертификату LDAPS, атрибуты каталога и Windows Veyon Service. Не следует смешивать ошибки аутентификации пользователя, поиска компьютеров и правил удалённого доступа.

Для отката сохраните конфигурации PAM/Veyon и сведения об исходном пакете. Учитывайте, что обновление Veyon может заменить локально исправленный helper. Права на keytab и пароль LDAP-учётной записи должны контролироваться отдельно.

Итог

Ubuntu может использовать доменные учётные записи для Veyon и получать компьютеры из AD без присоединения Linux к домену. При этом ответственность разделена: Kerberos/PAM — аутентификация оператора, LDAPS — каталог, Windows Veyon Service — удалённый доступ и его ограничения. Главное в таком внедрении — не только добиться рабочего подключения, но и подтвердить отказ для неавторизованных пользователей.