Администрирование · 12 мин
Под каким пользователем работает сервер 1С и как это проверить
Под каким пользователем работает сервер 1С: как узнать учётную запись службы агента, какие права ей нужны и как безопасно сменить пользователя в Windows и Linux.
Сервер 1С:Предприятие — это служба операционной системы, и она всегда работает от имени какой-то учётной записи. От того, какой именно пользователь указан для службы агента сервера, зависят права на каталоги служебных файлов, доступ к сетевым ресурсам, возможность подключения к СУБД и даже успешный запуск кластера после перезагрузки. Ошибки вроде «кластер серверов не обнаружен» или отказа в доступе к каталогу srvinfo чаще всего связаны именно с учётной записью службы.
По умолчанию при установке на Windows агент сервера 1С регистрируется от имени локальной системной учётной записи (LocalSystem) либо от специально созданного пользователя USR1CV8, если администратор выбрал этот вариант в установщике. На Linux агент обычно работает от пользователя usr1cv8, который создаётся пакетом установки. Каждый вариант имеет свои ограничения, и в ряде сценариев учётную запись приходится менять.
Ниже разобрано, как определить текущего пользователя службы, какие права ему необходимы, в каких случаях стандартной учётной записи недостаточно и как безопасно выполнить смену пользователя, не сломав работающий кластер.
Какие учётные записи использует сервер 1С по умолчанию
При установке сервера 1С на Windows установщик предлагает два варианта: запускать службу от имени системной учётной записи или создать отдельного пользователя USR1CV8. В первом случае служба получает широкие локальные права, но с точки зрения сети представляет собой учётную запись компьютера. Во втором случае создаётся локальный пользователь с ограниченными правами, которому установщик автоматически выдаёт доступ к каталогу srvinfo и необходимым веткам реестра.
На Linux-дистрибутивах пакеты сервера 1С создают системного пользователя usr1cv8 и одноимённую группу grp1cv8. Демон агента сервера запускается от этого пользователя, а каталог /opt/1cv8 и служебные файлы кластера получают соответствующего владельца. Менять эту схему без необходимости не рекомендуется: скрипты запуска и обновления рассчитаны именно на неё.
Важно понимать разницу между пользователем службы агента и пользователями информационных баз. Учётная запись службы — это сущность операционной системы, она не имеет отношения к списку пользователей в конфигураторе. Путаница между этими уровнями — частая причина неверных настроек прав.
Как узнать, под каким пользователем работает служба
Самый простой способ на Windows — открыть оснастку «Службы» (services.msc), найти службу с именем вида «Агент сервера 1С:Предприятия 8.3.x (x86-64)» и открыть её свойства. На вкладке «Вход в систему» указана учётная запись: «Локальная системная учётная запись» означает LocalSystem, а «С указанной учётной записью» покажет конкретного пользователя, например .\USR1CV8 или DOMAIN\srv1c.
Тот же результат даёт командная строка. Команда sc qc "1C:Enterprise 8.3 Server Agent (x86-64)" выведет параметры службы, включая строку SERVICE_START_NAME — это и есть учётная запись. Имя службы может отличаться в зависимости от разрядности и версии платформы, точное имя видно в свойствах службы на вкладке «Общие».
На Linux проверка выполняется командой ps aux | grep ragent — в первой колонке вывода виден пользователь, от которого запущен процесс агента. Дополнительно можно посмотреть юнит systemd: systemctl status srv1cv83 покажет и пользователя, и параметры запуска.
sc qc "1C:Enterprise 8.3 Server Agent (x86-64)" | findstr SERVICE_START_NAMEКакие права нужны учётной записи службы
Минимальный набор прав — полный доступ к каталогу служебных файлов кластера. На Windows это по умолчанию каталог srvinfo внутри каталога установки платформы либо путь, заданный параметром -d при регистрации службы. Без полного доступа к этому каталогу агент не сможет читать реестр кластера и журнал регистрации кластера, и сервер не запустится.
Дополнительно учётной записи могут понадобиться: доступ на чтение к каталогу установки платформы и лицензиям, право записи в каталоги журналов и дампов (если настроен технологический журнал), доступ к сетевым папкам, если кластерные данные или шаблоны лежат на файловом сервере. Для доменной учётной записи права на каждый такой ресурс выдаются явно — наследование от LocalSystem здесь не работает.
Права администратора на сервере учётной записи службы не нужны и нежелательны. Принцип минимальных привилегий снижает ущерб при компрометации: процесс с правами администратора домена или локального администратора превращает любую уязвимость в полный контроль над системой. Достаточно обычного пользователя с точечно выданными разрешениями.
Когда стандартной учётной записи недостаточно
Типичный сценарий — доступ к сетевым ресурсам. Процессы, работающие от LocalSystem, обращаются к сети от имени учётной записи компьютера, и многие файловые серверы и СУБД такой доступ не принимают. Если фоновые задания 1С должны писать файлы на сетевую шару или используется Windows-аутентификация к MS SQL Server, службу переводят на доменную учётную запись.
Второй сценарий — требования политики безопасности. Во многих организациях регламент запрещает службам работать от встроенных системных учётных записей и требует выделенных сервисных аккаунтов с управляемыми паролями. В этом случае создают доменного пользователя (или gMSA — управляемую сервисную учётную запись, если инфраструктура её поддерживает) и перенастраивают службу.
Третий случай — разделение сред. Если на одном сервере развёрнуто несколько кластеров (продуктивный и тестовый), их иногда запускают под разными учётными записями, чтобы изолировать права на каталоги и сетевые ресурсы друг от друга.
Как выбрать учётную запись
Как безопасно сменить пользователя службы на Windows
Порядок действий начинается с подготовки. Создайте учётную запись (локальную или доменную), выдайте ей полный доступ к каталогу srvinfo и, при необходимости, к каталогам лицензий, журналов и сетевым ресурсам. Убедитесь, что у учётной записи есть право «Вход в качестве службы» — доменные политики иногда его не выдают по умолчанию, и тогда служба не запустится с ошибкой входа.
Далее остановите службу агента сервера, убедившись, что пользователи завершили работу. В свойствах службы на вкладке «Вход в систему» укажите новую учётную запись и пароль, либо используйте команду sc config с параметрами obj и password. После этого запустите службу и проверьте результат.
Признак успеха — служба перешла в состояние «Работает», в оснастке управления сервером 1С (или через rac) виден кластер со списком информационных баз, а в каталоге srvinfo появляются актуальные записи журналов. Если служба стартует и сразу останавливается — почти всегда это нехватка прав на каталог кластера или неверный пароль.
- 1Создайте учётную запись и выдайте ей полный доступ к каталогу srvinfo и другим нужным каталогам
- 2Проверьте наличие права «Вход в качестве службы» (локальная политика безопасности или GPO)
- 3Остановите службу агента сервера 1С после завершения сеансов пользователей
- 4Укажите новую учётную запись в свойствах службы на вкладке «Вход в систему»
- 5Запустите службу и проверьте доступность кластера и информационных баз
- 6При ошибке запуска проверьте права на каталоги и пароль учётной записи
Особенности на Linux и типичные ошибки
На Linux смена пользователя встречается реже, но если она нужна, последовательность аналогична: создать пользователя, передать ему владение каталогами платформы и кластера командой chown -R, скорректировать юнит systemd (директива User=) и перезапустить службу. Пропуск шага смены владельца файлов — главная причина отказа запуска после такой перенастройки.
Среди типичных ошибок при работе с учётной записью службы выделяются несколько повторяющихся. Первая — смена пользователя без выдачи прав на srvinfo: служба стартует и тут же падает, кластер недоступен. Вторая — истёкший или сменённый пароль доменной учётной записи: после перезагрузки сервера служба не поднимается, и базы оказываются недоступны до восстановления пароля. Третья — выдача учётной записи прав администратора домена «чтобы наверняка заработало»: это создаёт серьёзный риск безопасности без реальной необходимости.
Ещё одна ошибка — использование личной учётной записи администратора для службы. При увольнении сотрудника или блокировке его аккаунта сервер 1С перестаёт работать. Служебные процессы должны работать от выделенных сервисных учётных записей, не привязанных к конкретным людям.
Как проверить результат
Статус «Работает», в диспетчере задач процесс ragent запущен от нового пользователя
Служба останавливается сразу после запуска или выдаёт ошибку входа
Консоль управления или rac видит кластер, рабочие процессы и базы
Кластер не обнаружен, список баз пуст
Журналы кластера обновляются, новых ошибок доступа нет
В журналах событий ОС ошибки отказа в доступе к файлам кластера
Сеансы подключаются, регламентные задания выполняются
Ошибки подключения к серверу или сбои фоновых заданий с сетевыми ресурсами
Часто задаваемые вопросы
Можно ли оставить сервер 1С на LocalSystem, это безопасно?
Технически можно, и для изолированного сервера без сетевых ресурсов это рабочий вариант. Однако LocalSystem имеет максимальные права на локальной машине, поэтому при компрометации процесса злоумышленник получает полный контроль над сервером. Если политика безопасности организации это допускает и сетевой доступ не нужен — вариант допустим, но выделенная учётная запись с минимальными правами предпочтительнее.
Почему после смены пароля доменного пользователя сервер 1С перестал работать?
Пароль учётной записи хранится в настройках службы и не обновляется автоматически при смене пароля в домене. После смены пароля нужно открыть свойства службы и заново ввести актуальный пароль на вкладке «Вход в систему». Чтобы избежать таких ситуаций, для сервисных учётных записей задают неистекающий пароль или используют управляемые сервисные аккаунты gMSA.
Нужна ли учётной записи службы роль администратора сервера?
Нет. Для работы агента сервера достаточно прав на каталоги кластера, платформы, лицензий и журналов, а также права «Вход в качестве службы». Права локального или доменного администратора избыточны и увеличивают ущерб при возможной компрометации процесса.
Как узнать пользователя службы, если сервер удалённый и нет доступа к консоли?
Можно выполнить запрос удалённо через командную строку: sc \\имя_сервера qc "имя службы" — при наличии соответствующих прав. Альтернатива — PowerShell с Get-WmiObject Win32_Service с фильтром по имени службы, поле StartName покажет учётную запись. На Linux достаточно SSH-доступа и команды ps aux с фильтром по ragent.
Что делать, если служба не запускается после смены учётной записи?
Сначала проверьте журнал событий Windows (раздел «Система» и «Приложение») — там будет конкретная ошибка: отказ в доступе, неверный пароль или отсутствие права входа как служба. Чаще всего помогает выдача полного доступа к каталогу srvinfo и проверка права «Вход в качестве службы» в локальной политике безопасности. Если быстро решить не удаётся, можно вернуть прежнюю учётную запись и восстановить работу, а разбирательство продолжить в тестовой среде.
Влияет ли пользователь службы на подключение к базе данных MS SQL или PostgreSQL?
Да, если используется Windows-аутентификация к СУБД: в этом случае сервер 1С обращается к базе от имени учётной записи службы, и именно ей нужны права на базы данных. При аутентификации средствами самой СУБД (логин и пароль задаются в свойствах информационной базы) учётная запись службы на подключение не влияет.
Что важно запомнить
Сервер 1С работает от учётной записи операционной системы: по умолчанию LocalSystem или USR1CV8 на Windows и usr1cv8 на Linux. Проверить её можно в свойствах службы или командой sc qc. Менять учётную запись нужно только под конкретную задачу — сетевой доступ или доменную аутентификацию — с обязательной выдачей прав на каталог srvinfo и проверкой запуска кластера после переключения.