Windows

Veyon с Windows вне домена и компьютерами Active Directory: аутентификация, диагностика и развёртывание через GPO

Практический кейс Veyon 4.11.3: Windows WORKGROUP как Veyon Master, доменные клиенты, локальная учётная запись, ошибки 4625 и Access Control, DNS/NAT, PowerShell и GPO-развёртывание v1.3.

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

Проверено на: Veyon 4.11.3 · Windows 11 WORKGROUP · Windows 10/11 AD clients · Active Directory · PowerShell 5.1 · Group Policy Preferences

Задача и границы кейса

Требовалось управлять Windows-компьютерами, состоящими в Active Directory, через Veyon Master на Windows 11, который не включён в домен (WORKGROUP). В той же инфраструктуре Veyon Service развёртывался на доменных рабочих станциях через GPO и PowerShell. В октябре 2026 года удалось восстановить подключение из WORKGROUP, а также проверить отдельные партии автоматического развёртывания.

Этот кейс не про Ubuntu: интеграция Veyon Master на Ubuntu без realm join описана в отдельной статье.

Все имена серверов, компьютеров, домена, пользователей, групп и OU ниже заменены примерами. Показанные PowerShell-команды служат для проверки и не содержат производственных паролей. Теперь исходный PowerShell-скрипт Install-Veyon-v1.3.ps1 изучен отдельно; в публикацию включён обезличенный демонстрационный шаблон. Шаблон намеренно не готов к запуску: в нём отсутствуют реальные SHA256, домен, группа доступа и доверенные сети. Это не дословная копия рабочего файла и не универсальный безопасный установщик.

Схема

Windows 11 / WORKGROUP
  Veyon Master 4.11.3
  локальная учётная запись operator1
        |
        +---- DNS -> имена доменных компьютеров
        +---- LDAPS :636 -> AD (каталог, OU, компьютеры)
        +---- TCP/11100 -----------------------------+
                                                     |
                                        Windows / AD domain member
                                        Veyon Service 4.11.x
                                        Logon authentication
                                        Access Control по группе AD
                                                     |
                                              AD / Domain Controller

Контур развёртывания (только доменные клиенты):
GPO -> Scheduled Task (SYSTEM) -> Install-Veyon-v1.3.ps1 -> EXE/config/service/firewall

Три проверки нельзя смешивать: LDAP показывает список компьютеров; Windows проверяет переданные учётные данные; правила Veyon определяют, имеет ли аутентифицированный оператор право подключаться.

1. Что работало до исправления

До устранения проблемы было подтверждено:

Veyon Master 4.11.3 запускается на недоменном Windows 11;
LDAPS и получение OU/компьютеров AD работают;
Test-NetConnection до доменного клиента по TCP/11100 проходит;
Veyon Service на клиенте работает и слушает порт;
доменная учётная запись оператора входит в предусмотренную группу доступа;
отдельная проверка доступа к контроллеру домена под доменными реквизитами выполняется успешно.

Тем не менее подключение из Veyon Master отклонялось. Сетевая доступность, LDAP и даже успешный net use не означают, что Veyon передаёт на удалённый компьютер ту же учётную запись.

2. Сначала DNS и маршрутизация, затем аутентификация

В ходе диагностики обнаружилась отдельная сетевая причина: DNS redirect на шлюзе перехватывал запросы от недоменного сегмента. После добавления исключений для запросов к DNS-контроллерам домена стали корректно разрешаться имена внутренних рабочих станций.

На компьютере с Veyon Master:

Resolve-DnsName pc01.ad.example.com
Resolve-DnsName dc01.ad.example.com
Test-NetConnection pc01.ad.example.com -Port 11100
Test-NetConnection dc01.ad.example.com -Port 636

На целевом доменном ПК:

Get-Service VeyonService -ErrorAction SilentlyContinue
Get-NetTCPConnection -LocalPort 11100 -State Listen -ErrorAction SilentlyContinue

Проверяйте реально используемые DNS и правила NAT, а не только IP-доступность. Исключения DNS на маршрутизаторе следует ограничивать только необходимыми запросами и сетями. Проблема DNS была устранена раньше, чем проблема аутентификации.

3. Почему доменные реквизиты не сработали из WORKGROUP

Попытки указать пользователя как CORP\operator1 и operator1@ad.example.com не привели к нужному результату. При этом журнал Security на целевой Windows фиксировал события 4625 (LogonType 3) с другим именем пользователя, не соответствующим ожидаемому доменному оператору.

В тестовых событиях встречались 0xC000006D (ошибка входа) и 0xC000006A (неверный пароль для указанной учётной записи). Это указывало, что проблема уже перешла с уровня транспорта на уровень контекста проверяемой учётной записи.

Параллельно встречалась другая стадия отказа: Veyon фиксировал успешную VNC-аутентификацию, после чего Access Control отклонял доступ, поскольку проверяемая учётная запись не соответствовала условию членства в разрешённой группе. Это два разных диагноза:

Наблюдение	Что проверять
TCP/11100 закрыт	Служба, firewall, ACL и маршрутизация
Есть 4625, пароль/логин не принят	Какая учётная запись и домен действительно попали на целевой ПК
VNC authentication succeeded, затем Access Control denied	Эффективную идентичность пользователя и условия правил Veyon
LDAP показывает компьютеры, но Veyon не подключается	Не LDAP, а аутентификацию/авторизацию или службу

События следует читать на целевом компьютере, где проходит проверка входа, сопоставляя метки времени с попыткой подключения из Master.

4. Сработавшее решение: совпадающая локальная учётная запись

На недоменном компьютере с Veyon Master создали локальную учётную запись operator1, соответствующую доменному оператору по имени и паролю. После этого подключение к доменным рабочим станциям заработало.

Объяснение согласуется с принципом Logon authentication: Veyon передаёт учётные данные на удалённую Veyon Service, где Windows выполняет проверку. Для работы в неоднородном окружении важна реальная идентичность, которую проверяет удалённая сторона. Документация Veyon также указывает необходимость согласованных пользовательских учётных записей/паролей для этого режима.

Чего этот тест не доказывает: локальная учётная запись не стала доменной, доверительные отношения между WORKGROUP и AD не появились. Без отдельного анализа успешного Security 4624 и эффективных групп нельзя утверждать, каким именно механизмом Windows сопоставила идентичность в каждой сессии. Нужно отдельно проверить, что целевая машина действительно авторизовала нужного доменного оператора, а не более широкое разрешающее правило.

Безопасность. Совпадающий пароль у локальной и доменной учётных записей увеличивает риск повторного использования учётных данных. Это локальное проверенное решение, а не рекомендуемый стандарт массового развёртывания. Для постоянной эксплуатации предпочтительны доменная рабочая станция администратора либо продуманная схема Veyon key-file authentication с защищённым доступом к закрытому ключу. При смене доменного пароля локальная копия не синхронизируется автоматически. Не добавляйте оператора в локальные Administrators, если это не требуется.

5. Как отделить ошибку Logon Authentication от Access Control

На доменном клиенте проверялись настройки Veyon, включающие использование групп домена и ограничение доступа группой операторов. Вывод UserGroups/UseDomainUserGroups=true сам по себе не гарантирует, что любой локальный пользователь распознаётся как член доменной группы.

Проверить установленную конфигурацию можно так:

$Cli = 'C:\Program Files\Veyon\veyon-cli.exe'
& $Cli config get 'UserGroups/Backend'
& $Cli config get 'UserGroups/UseDomainUserGroups'
& $Cli config get 'AccessControl/AccessRestrictedToUserGroups'

Названия некоторых параметров зависят от версии и сборки; команда veyon-cli config get вернёт текущее значение либо диагностическую ошибку. Не следует интерпретировать устаревшие или несуществующие ключи как достоверную причину сбоя.

В Veyon Configurator → Access control проверяйте порядок правил, условие Accessing user is member of group, выбранный backend групп и поведение при отсутствии совпадения. В нормальной конфигурации доступ не должен открываться всем пользователям ради успешного теста.

6. Диагностика событий Windows

На целевом компьютере, в PowerShell с правами чтения журнала Security, непосредственно после попытки подключения:

$since = (Get-Date).AddMinutes(-10)
Get-WinEvent -FilterHashtable @{
    LogName='Security'; Id=4624,4625; StartTime=$since
} -ErrorAction SilentlyContinue | ForEach-Object {
    [xml]$xml = $_.ToXml()
    $fields = @{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fields[$item.Name] = $item.'#text'
    }
    [pscustomobject]@{
        Time=$_.TimeCreated; EventId=$_.Id
        User=$fields.TargetUserName; Domain=$fields.TargetDomainName
        LogonType=$fields.LogonType; Status=$fields.Status
        SubStatus=$fields.SubStatus; SourceIP=$fields.IpAddress
    }
} | Format-Table -AutoSize

Нас интересуют TargetUserName, TargetDomainName, LogonType, Status и SubStatus. Помните, что не все события 4624/4625 вызваны Veyon: сопоставляйте время, источник и процесс. Полные журналы могут содержать имена пользователей/IP и требуют обезличивания перед публикацией.

На Master дополнительно смотрите VeyonMaster.log, на клиенте — доступные журналы Veyon и Windows; имя и расположение файлов логов зависят от настроек версии. Само отсутствие файла с предполагаемым именем — не доказательство отсутствия событий.

7. Разбор фактического `Install-Veyon-v1.3.ps1`

Важное уточнение: это EXE-установщик Veyon, который запускается с аргументами /S /NoMaster, не MSI. Скрипт рассчитан на Windows 10/11 (CIM Win32_OperatingSystem.ProductType = 1), запускается задачей GPO от LOCAL SYSTEM и сознательно не работает на Windows Server/контроллерах домена. Он устанавливает Veyon Service, но не Master.

Слой 1. Ограничение области применения

#Requires -Version 5.1 и строгий режим PowerShell.
Проверка ProductType = 1 (рабочая станция) и SID S-1-5-18 (SYSTEM) для реального развёртывания.
Именованный Global\... mutex предотвращает одновременную работу двух экземпляров.
Проверка активных профилей Windows Firewall: профиль должен быть включён, а входящие подключения по умолчанию не должны разрешаться.
Предусмотрен -WhatIfCheck: он не запускает установку и не меняет firewall, но не является абсолютно read-only: до выхода создаются каталоги/записываются логи, а при проверке конфигурации может создаваться защищённый временный каталог.

Слой 2. Репозиторий, manifest и защита от подмены

Скрипт читает manifest.json из NETLOGON и требует точную версию 4.11.3.0. В самом скрипте жёстко закреплены SHA256 для установщиков x64/x86 и конфигурационного JSON. Хеши сначала сверяются с manifest, затем с файлами на сетевой шаре и ещё раз — после копирования в локальный кэш. Установщик дополнительно проходит Get-AuthenticodeSignature: проверяется Status = Valid и ожидаемый субъект сертификата Veyon Solutions.

Это позволяет отсеивать повреждённый либо незапланированно заменённый дистрибутив. Однако проверка одного поля Subject не равна закреплению сертификата по thumbprint: доверие цепочке подписанта и поставщику пакета должно обеспечиваться штатной политикой. Результаты проверки нельзя переносить на произвольные сторонние EXE.

\\ad.example.com\NETLOGON\Software\Veyon\
├── manifest.json
├── Packages\...
├── Config\...
└── Scripts\Install-Veyon-v1.3.ps1

Слой 3. Установка и исправление зависаний v1.2

Ключевое изменение в v1.3 — запуск EXE через .NET System.Diagnostics.ProcessStartInfo с UseShellExecute = false, CreateNoWindow = true. Скрипт ожидает завершения максимум 600 секунд, затем проверяет ExitCode = 0; при таймауте пытается завершить процесс и фиксирует ошибку. Это заменило проблемный способ запуска из предыдущей редакции v1.2.

Новая версия не выполняет безусловный upgrade: обнаружив уже установленную Veyon другой версии, скрипт прекращает работу с сообщением manual upgrade review needed. Обновление до другой версии требует отдельного пересмотра manifest, хешей, конфигурации и процедуры upgrade.

Слой 4. Безопасное включение Veyon Service

Перед первой установкой создаётся временное правило Block TCP/11100 inbound. Затем импортируется проверенный JSON конфигурации, отключаются другие включённые входящие правила Allow, в названии которых обнаружено Veyon, и настраивается отдельное Allow TCP/11100 только для явно разрешённых адресов. Существующие посторонние правила firewall скрипт не трогает.

После этого он переводит VeyonService в Automatic, перезапускает службу, проверяет её состояние Running, версию veyon-cli.exe и эффективную конфигурацию. Только после успешной проверки снимается временная блокировка. При ошибке блокирующее правило остаётся, поэтому после сбоя важно читать журнал развёртывания, а не отключать правило вслепую.

Дополнительно обнаружен нюанс Veyon 4.11.3: veyon-cli config get может вернуть пустую строку для корректного Network/VeyonServerPort, хотя config export содержит 11100. Поэтому скрипт экспортирует эффективный JSON во временный каталог с ACL только для SYSTEM и Administrators, сверяет группу операторов, параметры доменных групп, firewall и порт, затем удаляет временный файл.

Слой 5. Идемпотентность

Повторная установка не нужна, только когда одновременно совпадают: версия, работа службы, контрольное состояние (версия/архитектура/хеши), точные параметры разрешающего правила firewall, экспортированная конфигурация и отсутствие временного Block-правила. Тогда журнал содержит:

Already current; configuration, service and firewall checks OK

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

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

$TaskName = 'Corp-Veyon-AutoDeploy' # имя для примера
Get-ScheduledTask -TaskName $TaskName -ErrorAction SilentlyContinue |
    Select-Object TaskName, State, @{N='RunAs';E={$_.Principal.UserId}}
Get-ScheduledTaskInfo -TaskName $TaskName -ErrorAction SilentlyContinue |
    Select-Object LastRunTime, LastTaskResult, NextRunTime
Get-Service VeyonService -ErrorAction SilentlyContinue
Get-NetFirewallRule | Where-Object DisplayName -Like '*Veyon*' |
    Select-Object DisplayName, Enabled, Direction, Action
Get-Content "$env:ProgramData\Example\Veyon\deploy.log" -Tail 30 # условный путь

LastTaskResult = 0 следует сопоставлять с содержимым лога и проверками службы/firewall: код задачи сам по себе не подтверждает, что нужная конфигурация применена.

В контрольной партии было подтверждено 83 из 85 установок. На двух оставшихся станциях имелись отдельные проблемы с запуском установщика (0xC0000142); после перезагрузки и повторной проверки Veyon Service работала, а ошибка не воспроизводилась. Первопричина 0xC0000142 не установлена. Эти результаты не следует превращать в утверждение о постоянном 100% охвате всех компьютеров.

Полезные результаты предыдущего этапа — проверка одинакового скрипта на обоих DC, повторный запуск с Already current, диагностика SYSVOL/NETLOGON и запуск задач под SYSTEM. GPO применяется к доменным рабочим станциям; WORKGROUP Master не получает такую политику.

Полный алгоритм можно изучить в публичном обезличенном примере Install-Veyon-v1.3-example.ps1. Он преднамеренно содержит невалидные SHA256 и RFC 5737-адреса, поэтому не может использоваться как есть.

8. Диагностический PowerShell-скрипт

Для воспроизводимой первичной проверки подготовлен отдельный read-only скрипт Veyon-Diagnostics.ps1. Он проверяет DNS, TCP/11100, наличие veyon-cli.exe, состояние службы, конфигурационные ключи и сведения о Scheduled Task. Он не создаёт пользователей, не меняет firewall и не запускает MSI.

Пример:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\Veyon-Diagnostics.ps1 `
  -TargetHost pc01.ad.example.com -TaskName Corp-Veyon-AutoDeploy

Для диагностики входов Security 4624/4625 используйте команду из раздела 6 непосредственно на целевом Windows-хосте. Производственный Install-Veyon-v1.3.ps1 — другой файл: в этой публикации не заявляется, что диагностический скрипт является его исходником или полной копией.

Исходный код и история изменений на GitHub

Veyon GPO Deployment — исходники PowerShell и документация — отдельный репозиторий с текущим демонстрационным scripts/Install-Veyon.ps1, диагностическим scripts/Veyon-Diagnostics.ps1 и инструкцией по настройке GPO.

В каталоге history/ опубликованы обезличенные версии v1.0–v1.3; точные изменения между ними описаны в CHANGELOG на русском.

Важно: это адаптированные публичные примеры, а не побайтовые копии production-скриптов. Контрольные суммы и параметры инфраструктуры намеренно заменены; перед применением требуется собственная проверка, а модифицированные версии не проходили отдельное тестирование на Windows.

Итоги и границы результата

Сетевая проблема DNS redirect была устранена отдельно от Veyon.
LDAPS и TCP/11100 подтвердили инфраструктурную доступность, но не право доступа.
Windows Security 4625 выявил передачу не той идентичности/ошибку проверки пароля; Access Control затем дал самостоятельную точку отказа.
Локальная учётная запись на WORKGROUP Master с совпадающими реквизитами помогла подключиться к доменным ПК в данном окружении.
Install-Veyon-v1.3.ps1 проверен по исходному коду и результатам контрольных запусков; полную корректность всего парка из одного аудита вывести нельзя.
Следующая обязательная проверка для безопасности — успешный вход с указанием нужной личности в 4624 и отказ пользователю вне разрешённой группы, без временно открытых разрешающих правил.