В современных IT-инфраструктурах службы безопасности все чаще требуют использовать для автоматизированных задач и сервисов специальные учетные записи, такие как групповые управляемые учетные записи служб (gMSA). Это позволяет повысить безопасность за счет автоматического управления паролями и ограничения прав. Рассмотрим ситуацию, когда необходимо настроить запуск пакетного задания 1С (например, восстановление базы из *.dt файла) через Планировщик задач Windows от имени gMSA. При такой настройке можно столкнуться с неожиданными ошибками аутентификации и лицензирования, даже если все права доступа кажутся верными.
В этой статье разберем реальный пример, проанализируем лог ошибок и найдем причину сбоя, которая оказалась не в правах доступа, а в особенностях работы конфигуратора 1С.
Итак, перед нами стоит задача: запустить 1С в пакетном режиме для восстановления информационной базы. Задание настроено в Планировщике задач Windows и выполняется от имени gMSA-аккаунта (например, DOMAIN\User_gMSA$). Для пользователя 1С в конфигураторе установлена аутентификация операционной системой и указан соответствующий gMSA-пользователь. Для безошибочной подготовки параметров пакетного запуска можно использовать конструктор командной строки 1С.
Командный файл (bat) для запуска выглядит примерно так:
START "" /wait "C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" CONFIG /S Сервер:1541\БД /DisableUnrecoverableErrorMessage /DisableStartupDialogs /UseHwLicenses+ /WA+ /DisableStartupMessages /RestoreIB "Путь до *.dt" /OUT "Путь до log.txt"
После запуска задания процесс 1cv8.exe стартует, но практически сразу завершается с ошибкой. Проанализируем логи, чтобы выяснить причину.
В логах появляется крайне неожиданная запись, особенно если мы используем аппаратные ключи HASP:
0874860b-2b41-45e1-bc2b-6e186eb37771: Ошибка программного лицензирования. Файл программной лицензии не предусматривает возможность запуска клиентских приложений 1С:Предприятия или внешних соединений: file://C:/ProgramData/1C/licenses/.......lic
Система почему-то пытается найти программную лицензию, хотя в параметрах запуска указан ключ /UseHwLicenses+, принудительно включающий поиск аппаратных ключей.
В этом файле мы видим прямое следствие проблемы с аутентификацией:
Пользователь ИБ не идентифицирован
Вывод: Платформа 1С, запущенная от имени gMSA, не может ни получить лицензию, ни аутентифицировать пользователя в информационной базе, несмотря на использование ключа /WA+ (Windows Authentication).
Прежде чем мы перейдем к решению, рассмотрим стандартные шаги по диагностике, которые помогут исключить очевидные проблемы. Хотя в данном конкретном случае они не привели к успеху, в вашей ситуации они могут оказаться полезными.
Первый вопрос: "А дружит ли 1С с gMSA в принципе?". Как показала практика и ответ от линии консультаций 1С, для платформы тип учетной записи (обычный пользователь AD или gMSA) не имеет значения. 1С взаимодействует со стандартными механизмами аутентификации Windows. Таким образом, технических препятствий для использования gMSA нет. Проблема кроется в настройках, а не в совместимости.
Для фоновых заданий, особенно выполняемых от сервисных учетных записей, важны следующие параметры:
Проверьте, что эти флаги установлены в свойствах вашего задания.
Важный технический нюанс: учетные записи gMSA используют исключительно протокол аутентификации Kerberos и не поддерживают устаревший NTLM. Для корректной работы Kerberos необходимо, чтобы:
Если с Kerberos в вашей сети есть проблемы, аутентификация gMSA не пройдет. Это более глубокий уровень диагностики, но его стоит иметь в виду.
После долгих поисков причина проблемы оказалась довольно неожиданной и была связана с особенностью поведения Конфигуратора 1С.
Суть проблемы: при редактировании существующего пользователя 1С и смене его "Пользователя операционной системы" с обычного доменного аккаунта на gMSA-аккаунт, это изменение не всегда корректно сохранялось во внутренних данных информационной базы. Хотя в интерфейсе вы видели новое значение (DOMAIN\User_gMSA$), платформа при попытке аутентификации по-прежнему пыталась использовать старые данные.
Это объясняет, почему все работало для обычных пользователей и ломалось для gMSA, даже с идентичными правами.
Разберем по шагам, как исправить эту ситуацию:
После выполнения этих манипуляций и сохранения конфигурации, попробуйте запустить ваше задание из Планировщика еще раз. Проблема с аутентификацией и ошибкой лицензирования должна исчезнуть, и восстановление базы пройдет успешно. Для автоматизации регулярного восстановления базы по расписанию можно использовать готовое решение для обновления тестовой базы из рабочей.
Итог: Платформа 1С:Предприятие полностью совместима с gMSA. Если вы столкнулись с ошибками при запуске фоновых заданий от их имени, в первую очередь убедитесь, что настройки пользователя в Конфигураторе были применены корректно, пересохранив их. И только после этого переходите к проверке прав доступа и настроек Kerberos.