Процесс сервера 1С не может быть запущен: неправильная идентификация

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

Критичность ошибки высокая: пока она не устранена, кластер серверов 1С не работает, а значит, пользователи не могут подключиться к информационным базам через клиент-серверный вариант. Хорошая новость в том, что ошибка почти всегда локальная и устраняется без потери данных — достаточно восстановить корректные учётные данные службы.

Что означает ошибка неправильной идентификации

Сервер 1С:Предприятия состоит из нескольких процессов: агент сервера (ragent), менеджер кластера (rmngr) и рабочие процессы (rphost). Каждый из них запускается операционной системой как обычный процесс от имени какой-либо учётной записи Windows. Если при старте ОС не может подтвердить подлинность этой учётной записи — пароль не совпал, аккаунт отключён или удалён — процесс не создаётся, и в журнале появляется сообщение о неправильной идентификации.

Та же формулировка может встречаться и при запуске рабочего процесса из консоли кластера, если в свойствах рабочего сервера или кластера указаны неверные параметры аутентификации. В обоих случаях корень проблемы один: связка «имя пользователя + пароль», под которой должен работать процесс, не проходит проверку в системе безопасности.

Типичные причины возникновения ошибки

Самая частая причина — смена пароля учётной записи, под которой работает служба агента сервера 1С. Пароль меняют в Active Directory или локально, а в свойствах службы он остаётся старым. После перезагрузки сервера или перезапуска службы Windows пытается выполнить вход со старым паролем и отказывает в запуске.

Вторая группа причин — состояние самой учётной записи: она заблокирована после нескольких неудачных попыток входа, отключена администратором, удалена или у неё истёк срок действия. Третья группа — опечатки: имя пользователя указано без префикса домена, с лишним пробелом, либо служба настроена на локальную учётную запись, а сервер переведён в домен (или наоборот).

Реже встречаются ситуации, когда учётная запись лишена права «Вход в качестве службы» (Log on as a service) из-за изменений групповой политики. Формально это уже другая ошибка, но симптомы похожи — служба не стартует, и администратор ищет проблему в пароле, хотя дело в правах.

Диагностика: как найти источник проблемы

Начните с журнала событий Windows: откройте «Просмотр событий» → «Журналы Windows» → «Система» и найдите записи от источника Service Control Manager в момент сбоя. Событие с кодом 7000 или 7009 обычно содержит текст «не удалось запустить службу из-за ошибки входа», а событие 7038 прямо указывает, что службе не удалось войти в систему с текущим паролем.

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

Убедитесь, что указанный пользователь существует и активен. Для доменной учётной записи это делается в оснастке Active Directory — пользователи и компьютеры, для локальной — через «Управление компьютером» → «Локальные пользователи». Попытайтесь выполнить интерактивный вход на сервер под этой учётной записью: если вход невозможен, причина найдена.

Get-Service "1C:Enterprise*" | Select-Object Name, Status, StartType; Get-CimInstance Win32_Service -Filter "Name like '%1C%'" | Select-Object Name, StartName, State

Исправление учётных данных службы агента сервера

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

1. 1
   Откройте services.msc и найдите службу «Агент сервера 1С:Предприятия» нужной версии платформы
2. 2
   Остановите службу, если она находится в состоянии «Остановлена с ошибкой» — просто закройте предупреждения
3. 3
   Откройте «Свойства» → вкладка «Вход в систему»
4. 4
   Выберите «С учётной записью» и укажите имя в формате ДОМЕН\Пользователь или .\ЛокальныйПользователь
5. 5
   Введите актуальный пароль дважды и нажмите «Применить» — Windows сразу проверит подлинность
6. 6
   Убедитесь, что появилось сообщение о предоставлении права «Вход в качестве службы»
7. 7
   Запустите службу и проверьте, что она перешла в состояние «Работает»

Если при сохранении пароля Windows выдаёт ошибку «не удаётся проверить учётные данные», значит, пароль действительно неверный или учётная запись недоступна с этого сервера (например, нет связи с контроллером домена). Проверьте сетевое подключение сервера и доступность домена командой ping по имени контроллера.

После успешного запуска службы подождите одну-две минуты: агент должен поднять менеджер кластера и рабочие процессы. Проверить это можно в диспетчере задач — должны появиться процессы ragent, rmngr и rphost, запущенные от имени указанной учётной записи.

Настройка прав учётной записи службы

Даже с правильным паролем служба не запустится, если учётной записи не хватает прав. Минимально необходимое право — «Вход в качестве службы». Обычно Windows выдаёт его автоматически при назначении учётной записи в свойствах службы, но групповая политика домена может это право отзывать.

Проверить локальную политику можно через secpol.msc: «Локальные политики» → «Назначение прав пользователя» → «Вход в качестве службы». Если нужной учётной записи там нет, а добавить её невозможно из-за доменной политики, потребуется участие администратора домена — локальные изменения будут перезаписаны при следующем обновлении политик.

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

Ошибка при запуске рабочего процесса кластера

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

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

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

Как предотвратить повторение ошибки

Главная мера профилактики — выделенная сервисная учётная запись с паролем, который не истекает, либо управляемая сервисная учётная запись (gMSA), если инфраструктура домена это позволяет. Использование личной учётной записи администратора для службы — гарантированный источник будущих сбоев: стоит сменить пароль или уволиться сотруднику, и сервер 1С остановится.

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

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

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