В процессе администрирования серверных кластеров «1С:Предприятие» системные администраторы часто сталкиваются с аномалией: в журнале безопасности Windows (Security Event Log) фиксируются массовые события «Audit Failure» (неудачный вход) для учетной записи USR1CV8. При этом видимых проблем с работой пользователей в базах нет, но системный журнал буквально «заспамлен» записями о неудачных попытках авторизации с других серверов 1С. В этой статье мы детально разберем природу этого явления, проанализируем причины его возникновения в современных версиях платформы и реализуем пошаговое решение.
Рассмотрим типовой сценарий. В вашей инфраструктуре развернуто несколько серверов 1С. В журнале «Просмотр событий» на одном сервере вы видите записи, где в качестве источника входа указан IP-адрес соседнего сервера 1С, а в качестве субъекта — USR1CV8. Важный нюанс: ошибка возникает даже тогда, когда пароли локальных пользователей на всех серверах идентичны.
Выясним причину такого поведения. Дело в том, что в операционных системах Windows локальные учетные записи (даже с одинаковыми именами и паролями) имеют разные уникальные идентификаторы безопасности — SID. Когда сервер «А» пытается обратиться к сетевому ресурсу или программному интерфейсу сервера «Б» под локальным пользователем, сервер «Б» не может верифицировать эту учетную запись как свою, так как SID не совпадает. Это порождает ошибку авторизации.
Проанализируем изменения в платформе «1С:Предприятие». Начиная с релизов линейки 8.3.20 и выше, фирма «1С» существенно переработала и усилила механизмы проверки лицензионной чистоты. Теперь процессы кластера rmngr и rphost более интенсивно взаимодействуют друг с другом для:
Если в настройках кластера или в параметрах баз данных указаны сетевые пути (UNC-пути) к томам хранения файлов или серверу лицензирования, служба 1С инициирует сетевое обращение. Если служба запущена от имени локального USR1CV8, каждое такое обращение будет генерировать ошибку входа в журнале Windows.
Разберем наиболее эффективный и правильный с точки зрения архитектуры способ решения проблемы — использование доменной учетной записи для запуска службы ragent. Это обеспечит сквозную авторизацию между всеми серверами кластера, так как SID учетной записи будет един в рамках всего домена Active Directory.
Шаг 1: Подготовка учетной записи в Active Directory.
Создадим в домене специального пользователя, например, svc_1c_server. Для обеспечения безопасности и стабильности работы настроим следующие параметры:
Шаг 2: Назначение прав на серверах.
Доменная учетная запись должна обладать специфическим набором прав на каждом сервере, входящем в кластер 1С. Рассмотрим необходимые настройки в оснастке «Локальная политика безопасности» (secpol.msc):
svc_1c_server в политику Вход в качестве службы (Log on as a service).Шаг 3: Права на файловую систему.
Проанализируем папки, к которым служба должна иметь полный доступ. Нам необходимо предоставить права «Полный доступ» (Full Control) для svc_1c_server на следующие каталоги:
C:\Program Files\1cv8.C:\Program Files\1cv8\srvinfo.После перевода службы на доменную учетную запись многие администраторы замечают, что папка AppData\Local\Temp у этого пользователя начинает стремительно расти. Рассмотрим, почему это происходит и как этим управлять.
Средствами самой платформы 1С жестко ограничить размер этой папки невозможно, так как это системный механизм работы процессов. Однако мы можем предпринять следующие шаги:
TEMP для службы 1С. Это делается через редактирование параметров запуска службы в реестре или через переменные окружения среды для данной учетной записи. Рассмотрим вариант с параметром -t в строке запуска ragent.exe. Это позволит вынести временные файлы на отдельный быстрый диск (например, NVMe или RAM-диск), что не только решит проблему места на системном диске, но и ускорит работу.Рассмотрим пример простого скрипта PowerShell для очистки старых временных файлов, который можно добавить в планировщик задач Windows:
$TempPath = "C:\Users\svc_1c_server\AppData\Local\Temp"
$Days = 1
Get-ChildItem -Path $TempPath -Recurse | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$Days) } | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue
Проанализируем еще одну возможную причину неудачных авторизаций — внешние атаки. Если ваш сервер 1С доступен из интернета напрямую (без VPN), неудачные попытки входа под учетной записью USR1CV8 могут быть признаком попытки взлома или работы вредоносного ПО (майнеров, шифровальщиков). Для своевременного обнаружения таких подозрительных действий подойдет инструмент для мониторинга журнала событий безопасности и отправки email-уведомлений.
Рекомендации по защите:
HTTP/HTTPS.Подведем итог. Появление ошибок авторизации USR1CV8 в распределенной среде — это сигнал к тому, что локальная модель безопасности исчерпала себя. Переход на доменную учетную запись с правильной настройкой прав доступа и механизмов очистки временных файлов является промышленным стандартом, обеспечивающим стабильную и безопасную работу «1С:Предприятия 8.3».