Под каким пользователем выполняются фоновые задания 1С

Фоновое задание в 1С всегда выполняется в контексте какого-либо пользователя, и от того, какой именно, зависят права доступа к данным, видимость объектов и даже успешность самого запуска. Путаница возникает из-за того, что «пользователь» здесь существует на двух уровнях: пользователь информационной базы 1С и пользователь операционной системы, под которым работает серверный процесс.

Коротко: внутри базы фоновое задание выполняется от имени пользователя 1С, указанного при его создании (или пользователя, запустившего задание через ФоновыеЗадания.Выполнить()), а на уровне ОС код исполняется процессом рабочего сервера rphost (в клиент-серверном режиме) или процессом клиентского приложения (в файловом режиме). Эти два уровня нужно различать, чтобы правильно диагностировать ошибки прав доступа.

Два уровня «пользователя»: сеанс 1С и процесс ОС

Когда говорят «под каким пользователем выполняется фоновое задание», обычно смешивают две разные вещи. Первый уровень — пользователь информационной базы. Именно он определяет, какие роли и права применяются при обращении к данным: если у пользователя нет права на чтение регистра, фоновое задание при обращении к этому регистру получит ошибку, как и интерактивный сеанс.

Второй уровень — учётная запись операционной системы. В клиент-серверном варианте весь код фоновых заданий физически исполняется процессом rphost, который стартует от имени служебной учётной записи агента сервера 1С (по умолчанию на Windows это локальная учётная запись USR1CV8, на Linux — пользователь usr1cv8 или аналогичный, заданный при установке). Именно от имени этой учётной записи выполняются обращения к файловой системе, сетевым ресурсам, COM-объектам и внешним компонентам.

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

Кто становится пользователем сеанса фонового задания

При программном запуске через ФоновыеЗадания.Выполнить() пользователь явно не указывается — задание наследует пользователя текущего сеанса. Если обработку запустил менеджер Иванов, фоновое задание тоже будет выполняться от имени Иванова, с его ролями и ограничениями RLS.

У регламентных заданий ситуация иная. В свойствах регламентного задания есть поле «Пользователь» — именно от его имени создаётся сеанс фонового задания. Если поле не заполнено, сеанс создаётся без аутентифицированного пользователя (фактически от имени «пустого» пользователя), и код работает с полными правами, но функции, зависящие от текущего пользователя (например, ПользователиИнформационнойБазы.ТекущийПользователь() или подсистема «Пользователи» в БСП), могут вернуть пустое значение или вызвать ошибку.

Проверить, от чьего имени работает задание, можно в консоли заданий или в журнале регистрации: у событий фонового задания в поле «Пользователь» отображается именно пользователь информационной базы. Программно внутри задания это видно через ПользователиИнформационнойБазы.ТекущийПользователь().Имя.

Отличия файлового и клиент-серверного режимов

В файловом режиме нет отдельного сервера 1С, поэтому фоновые задания исполняются в процессе клиентского приложения, которое их запустило. С точки зрения ОС это процесс конкретного пользователя Windows, запустившего 1С. Если сеанс, запустивший задание, завершится, задание прервётся. Регламентные задания в файловой базе вообще не выполняются автоматически — для них нужен отдельный запущенный сеанс с выполнением ВыполнитьОбработкуЗаданий() или запуск с параметром /ExecuteScheduledJobs.

В клиент-серверном режиме задания исполняются рабочими процессами кластера rphost независимо от того, открыт ли у кого-то клиент. Процесс работает от имени учётной записи службы агента сервера. Это принципиально для сценариев, где задание обращается к внешним ресурсам: сетевым каталогам, почтовым серверам, FTP, веб-сервисам с аутентификацией Windows.

Какие права получает фоновое задание

Права фонового задания полностью определяются ролями пользователя ИБ, от имени которого оно выполняется. Если задание запущено от имени пользователя без права изменения документов, попытка записи документа завершится ошибкой нарушения прав доступа — точно так же, как в интерактивном сеансе.

Исключение — код, выполняемый в привилегированном режиме (УстановитьПривилегированныйРежим(Истина)) или в общих модулях с флагом «Привилегированный». В привилегированном режиме проверка прав отключается, и задание получает доступ к любым данным независимо от пользователя. Именно так обычно строятся регламентные обмены: пользователь задания может быть служебным и почти бесправным, а вся логика работает в привилегированном режиме.

Отдельно стоит упомянуть ограничение RLS (ограничение доступа на уровне записей). Оно применяется к фоновым заданиям так же, как к обычным сеансам: задание, запущенное от имени менеджера с ограничением по организации, увидит только «свои» данные. Если обмен должен видеть всё — либо запускайте его от служебного пользователя без RLS, либо используйте привилегированный режим.

Как настроить пользователя для регламентного задания

Рекомендуемая практика — завести в базе отдельного служебного пользователя, например «ФоновыеЗадания» или «РоботОбмен», и назначать его регламентным заданиям. Это упрощает аудит: в журнале регистрации сразу видно, какие действия выполнялись автоматически, а какие — людьми.

1. 1
   Создайте в базе пользователя, например «Служебный фоновый», без права интерактивной работы, если он не нужен.
2. 2
   Назначьте ему только те роли, которые реально требуются коду задания.
3. 3
   Откройте конфигуратор: Администрирование → Регламентные и фоновые задания, найдите нужное задание.
4. 4
   В свойствах задания укажите созданного пользователя в поле «Пользователь».
5. 5
   Запустите задание вручную и проверьте в журнале регистрации, от чьего имени прошёл сеанс и нет ли ошибок прав.

Если задание обращается к внешним ресурсам (сетевые папки, почта, веб-сервисы), дополнительно проверьте права учётной записи службы сервера 1С на стороне ОС. Для сетевых каталогов проще всего временно запустить под этой учётной записью тестовое обращение к ресурсу или назначить службе доменную учётную запись с нужными разрешениями.

В файловой базе для автоматического выполнения регламентных заданий запускают отдельный сеанс: ярлык с параметрами /ExecuteScheduledJobs и явным указанием пользователя через /N"ИмяПользователя". Этот сеанс должен быть постоянно запущен — иначе задания просто не стартуют.

Типичные проблемы и их диагностика

Самая частая жалоба — «задание падает с ошибкой доступа, хотя у меня всё работает». Причина почти всегда в различии пользователей: интерактивно вы работаете под собой, а задание — под служебным пользователем или вовсе без пользователя. Проверьте в журнале регистрации, от чьего имени выполнялся сеанс задания, и сравните роли.

Вторая типичная ситуация — ошибка «Отказано в доступе» при записи файла на сетевой диск. Здесь виноват не пользователь 1С, а учётная запись ОС процесса rphost: у локальной записи USR1CV8 обычно нет доступа к сетевым ресурсам других серверов. Решение — запускать службу агента сервера 1С под доменной учётной записью с нужными правами.

Третья группа проблем — функции, зависящие от текущего пользователя. Код, который в клиентском сеансе подставляет ответственного из настроек пользователя, в фоновом задании без пользователя вернёт пустое значение. Такие места нужно искать заранее и передавать пользователя параметром в метод фонового задания.

Контрольные точки

Как проверить результат

Пользователь сеанса задания в журнале регистрации

Норма

Совпадает с заданным в свойствах задания

Тревожный признак

Пусто или другой пользователь

Ошибки прав доступа

Норма

Событий «Отказано в доступе» нет

Тревожный признак

Ошибки при обращении к объектам метаданных

Запись файлов на сетевые ресурсы

Норма

Файлы создаются под учётной записью службы сервера

Тревожный признак

Ошибка доступа к сетевому пути

FAQ

Можно ли запустить фоновое задание от имени другого пользователя программно?

Штатного параметра «пользователь» у метода ФоновыеЗадания.Выполнить() нет — задание наследует пользователя текущего сеанса. Чтобы выполнить код от другого имени, используют регламентное задание с указанным пользователем и программно запускают его через метод Метаданные.РегламентныеЗадания, либо строят обмен через внешнее соединение.

Почему регламентное задание работает, но не видит данных пользователя?

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

Под каким пользователем Windows работает сервер 1С по умолчанию?

При стандартной установке на Windows служба агента сервера 1С запускается от имени локальной учётной записи USR1CV8, создаваемой установщиком. На Linux используется пользователь, заданный при установке (обычно usr1cv8). Изменить учётную запись можно в свойствах службы.

Опасно ли оставлять регламентное задание без пользователя?

С точки зрения прав — задание без пользователя работает без ограничений ролей, то есть фактически с полным доступом к данным. Для доверенного служебного кода это допустимо, но любая уязвимость в таком коде получит неограниченный доступ к базе. Безопаснее явно указывать служебного пользователя.

Как узнать, какие фоновые задания сейчас выполняются и от чьего имени?

Используйте обработку «Консоль заданий» (есть в составе типовых конфигураций на БСП и доступна как внешняя) — она показывает активные задания, их пользователей и состояние. Программно список получают методом ФоновыеЗадания.ПолучитьФоновыеЗадания() с отбором по состоянию.

Почему в файловой базе регламентные задания не выполняются сами?

В файловом режиме нет сервера, который планировал бы запуск. Нужен постоянно запущенный сеанс 1С, выполняющий обработку заданий, — либо отдельный запуск с параметром /ExecuteScheduledJobs, либо перенос базы в клиент-серверный режим.