Убедитесь, что у вас есть разрешение на запуск системных служб: причины и решение в 1С

Сообщение «Убедитесь, что у вас есть разрешение на запуск системных служб» появляется, когда платформа 1С:Предприятие пытается обратиться к системному компоненту Windows — чаще всего к службе агента сервера 1С, COM-соединению или DCOM-объекту — а учётная запись, под которой выполняется действие, не имеет на это прав. Ошибка типична для клиент-серверных установок, при работе через COM-connector, при запуске фоновых заданий и при обращении к серверу 1С с другого компьютера.

Корень проблемы всегда один: операционная система блокирует вызов на уровне безопасности Windows, а не на уровне самой 1С. Поэтому искать причину нужно в правах пользователя, настройках служб, разрешениях DCOM и политиках безопасности, а не в конфигурации прикладного решения. Менять код конфигурации или переустанавливать платформу в большинстве случаев не требуется.

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

В каких ситуациях возникает ошибка

Чаще всего сообщение встречается при запуске или перезапуске службы «Агент сервера 1С:Предприятия» из оснастки services.msc или из скрипта, когда команда выполняется от имени пользователя без административных прав. Второй типичный сценарий — обращение к серверу 1С через COM-соединение (V83.COMConnector) из внешнего приложения, скрипта или другой базы 1С: клиентский процесс не может создать COM-объект из-за ограничений DCOM.

Третья группа случаев — фоновые и регламентные задания на сервере, когда служба агента работает под специальной учётной записью (например, USR1CV8), а эта учётная запись утратила необходимые права после смены пароля, переноса сервера в другой домен или применения групповых политик. Наконец, ошибка может появиться при файловом варианте работы, если 1С пытается запустить вспомогательный процесс, а политики ограниченной учётной записи это запрещают.

Проверка учётной записи и её прав

Первый шаг — определить, под какой учётной записью выполняется действие, которое завершается ошибкой. Для службы агента сервера 1С откройте services.msc, найдите службу «Агент сервера 1С:Предприятия», откройте её свойства и посмотрите вкладку «Вход в систему». Там указано, работает ли служба под локальной системной учётной записью или под выделенным пользователем.

Если используется выделенная учётная запись, убедитесь, что она существует, не заблокирована и её пароль не истёк. Проверить это можно через оснастку «Локальные пользователи и группы» (lusrmgr.msc) или через Active Directory для доменной учётной записи. После смены пароля в домене его обязательно нужно обновить и в свойствах службы — иначе служба перестанет запускаться.

Учётная запись службы должна обладать правами «Вход в качестве службы» (Log on as a service). Это право назначается автоматически при указании пользователя в свойствах службы, но его может переопределить доменная групповая политика. Проверка выполняется через secpol.msc: «Локальные политики» → «Назначение прав пользователя» → «Вход в качестве службы».

Настройка прав на службу агента сервера 1С

Если службу должен запускать не администратор, а обычный пользователь или оператор, ему нужно явно выдать разрешение на запуск и остановку конкретной службы. Штатного графического интерфейса для этого в Windows нет, поэтому используется утилита командной строки sc.exe с параметром sdset, либо бесплатные средства вроде SubInACL, либо настройка через групповую политику «Системные службы».

Наиболее управляемый способ в доменной среде — групповая политика: «Конфигурация компьютера» → «Параметры Windows» → «Параметры безопасности» → «Системные службы». Там выбирается служба агента сервера 1С и задаётся список пользователей и групп с правами на запуск, остановку и чтение состояния. Это централизованное решение, которое не слетает при обновлении платформы.

Для разовой настройки на отдельном сервере можно использовать команду sc sdset с дескриптором безопасности в формате SDDL. Работа с SDDL требует аккуратности: ошибка в строке дескриптора может сделать службу недоступной даже для администраторов. Перед изменением сохраните текущий дескриптор командой sc sdshow, чтобы иметь возможность откатить настройку.

sc sdshow "1C:Enterprise 8.3 Server Agent"

Настройка разрешений DCOM для COM-соединений

Когда ошибка возникает при подключении через V83.COMConnector, причина почти всегда в разрешениях DCOM. Откройте консоль dcomcnfg, перейдите в «Службы компонентов» → «Компьютеры» → «Мой компьютер» → «Настройка DCOM» и найдите компонент, соответствующий коннектору 1С (V83.COMConnector). В его свойствах на вкладке «Безопасность» настраиваются три группы разрешений: запуск и активация, доступ и изменение конфигурации.

Для «Разрешений на запуск и активацию» выберите «Настроить» и добавьте учётную запись, из-под которой работает клиентский процесс, с правами «Локальный запуск» и «Локальная активация» (а при сетевом обращении — «Удалённый запуск» и «Удалённая активация»). Аналогично в «Разрешениях на доступ» добавьте учётную запись с правом «Локальный доступ» и при необходимости «Удалённый доступ».

Дополнительно проверьте ограничения по умолчанию для всего компьютера: свойства «Мой компьютер» → вкладка «Безопасность COM». Там задаются лимиты, которые применяются поверх индивидуальных настроек компонентов. Если учётной записи запрещён удалённый запуск на уровне лимитов, индивидуальные разрешения компонента не помогут.

Учётная запись службы агента: локальная система или выделенный пользователь

Выбор учётной записи для службы агента сервера 1С влияет и на появление ошибки, и на общую безопасность. Локальная системная учётная запись (Local System) имеет максимальные права на сервере, что устраняет большинство проблем с разрешениями, но создаёт риски: любой код, выполняемый на сервере 1С, получает права уровня системы. Выделенная учётная запись безопаснее, но требует аккуратной выдачи прав.

Если выбрана выделенная учётная запись, ей необходимы: право «Вход в качестве службы», полный доступ к каталогу служебных файлов сервера (srvinfo), доступ к СУБД, если используется клиент-серверный режим, и права на сетевые ресурсы, к которым обращаются регламентные задания (каталоги обмена, шаблоны, резервные копии).

Проверка результата и типичные ошибки

После внесения изменений проверьте результат в том же сценарии, где возникала ошибка: запустите службу, выполните COM-подключение или дождитесь запуска фонового задания. Для службы дополнительно убедитесь, что её состояние — «Работает», а в журнале событий Windows (eventvwr.msc, раздел «Система») нет новых ошибок с кодом 7000, 7009 или 7023 от источника Service Control Manager.

Для COM-сценариев полезно проверить журнал «Приложение» и журнал безопасности: события отказа в доступе DCOM фиксируются там и содержат идентификатор компонента и учётную запись, которой отказано. Это позволяет точно понять, какого разрешения не хватает, вместо перебора настроек вслепую.

Когда обращаться к администратору или специалисту

Самостоятельно безопасно выполнять проверку состояния службы, просмотр журналов событий и настройку прав на отдельном тестовом сервере. На продуктивном сервере, особенно входящем в домен, изменение дескрипторов безопасности, прав DCOM и политик лучше согласовать с системным администратором: ошибка может затронуть всех пользователей базы.

Отдельного внимания заслуживает ситуация, когда ошибка появилась внезапно без каких-либо изменений с вашей стороны. Это частый признак применения новой групповой политики, обновления Windows, сменившего настройки безопасности, или истечения пароля служебной учётной записи. В таком случае начинайте с выяснения, что изменилось в инфраструктуре, а не с перенастройки 1С.

Часто задаваемые вопросы