← На главную

Многие системные администраторы и специалисты по 1С сталкиваются с необходимостью изменения паролей технологических учетных записей. По требованиям аудита безопасности или регламентам компании, пароли от баз данных должны регулярно обновляться, а использование стандартной учетной записи sa (System Administrator) в Microsoft SQL Server вообще крайне не рекомендуется.

Рассмотрим типичную ситуацию: вы изменили пароль учетной записи sa на сервере MS SQL, после чего попытались обновить его в свойствах информационной базы в консоли администрирования серверов 1С. Однако система будто игнорирует новые настройки и при попытке входа выдает ошибку: Microsoft OLE DB Provider for SQL Server: Ошибка входа пользователя "sa". HRESULT=80040E4D, SQLSrvr: SQLSTATE=42000, state=1, Severity=E, native=18456. Перезапуск служб сервера 1С и самого SQL-сервера порой тоже не приносит результата. Разберем по шагам, почему это происходит, как обойти кэширование 1С и как безопасно перевести систему на новую учетную запись.

Почему консоль серверов 1С не применяет новый пароль?

Проанализируем ситуацию с технической точки зрения. Настройки кластера 1С, включая списки баз, имена пользователей СУБД и их пароли, хранятся в специальном конфигурационном файле. В версиях платформы 8.2 это файл 1CV8Reg.lst, а в более современных версиях 8.3 — 1CV8Clst.lst. Они располагаются в каталоге реестра кластера, например, %ProgramFiles%\1cv8\srvinfo\reg_1541\.

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

Способ 1: Обновление свойств всех баз

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

1. Откройте консоль администрирования серверов 1С:Предприятия.
2. Разверните ветку вашего кластера и перейдите в раздел "Информационные базы".
3. Откройте свойства каждой информационной базы, которая привязана к данной учетной записи SQL.
4. Заново введите пользователя СУБД и укажите новый пароль.
5. Сохраните изменения. После этого базы должны начать запускаться корректно.

Способ 2: Безопасное пересоздание регистрации базы в кластере

Часто администраторы боятся удалять регистрацию информационной базы из консоли 1С, полагая, что это приведет к потере Журнала регистрации. Рассмотрим подробнее этот миф. Журнал регистрации 1С (файлы формата .lgf, .lgp или базы SQLite формата .lgd) физически хранится не в базе данных MS SQL, а в файловой системе сервера 1С в подкаталоге с уникальным идентификатором базы внутри srvinfo.

Если изменить параметры соединения "мягким" способом не получается, мы можем безопасно перерегистрировать базу:

1. В консоли серверов 1С кликните правой кнопкой мыши по проблемной базе и выберите "Удалить".
2. В появившемся диалоговом окне обязательно выберите вариант Оставить без изменений. Это ключевой момент! Данный выбор удалит только "ссылку" на базу из списка кластера, но не тронет ни саму базу в MS SQL, ни файлы журнала регистрации на жестком диске.
3. Сразу после этого нажмите "Добавить" -> "Информационную базу".
4. Заполните все поля в точности так же, как они были заполнены ранее (имя базы в кластере, сервер баз данных, имя базы в MS SQL), но укажите уже новый логин и пароль для доступа к SQL.
5. Если имена и параметры совпадут, сервер 1С "подцепит" старый каталог с Журналом регистрации, и никаких потерь данных не произойдет.

Способ 3: Ручное редактирование файла конфигурации кластера (Жесткий метод)

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

1. Полностью остановите службу Агент сервера 1С:Предприятия (процесс ragent) через консоль служб Windows.
2. Убедитесь, что в диспетчере задач не осталось зависших процессов rmngr и rphost. Если они есть — завершите их принудительно.
3. Сделайте резервную копию файла 1CV8Reg.lst (или 1CV8Clst.lst), скопировав его в безопасное место.
4. Откройте оригинальный файл в любом текстовом редакторе (например, Notepad++).
5. Аккуратно найдите блок с параметрами вашей информационной базы. Там будет строка подключения, содержащая логин и хэшированный или зашифрованный пароль (в зависимости от версии платформы).
6. Если вы переводите базу на нового пользователя, вы можете вручную заменить имя пользователя (например, заменить sa на user_1c). С паролем сложнее из-за внутреннего шифрования 1С, поэтому этот метод лучше всего работает, когда мы меняем только логин, либо переносим строку конфигурации из заранее подготовленной тестовой базы с известным паролем.
7. Сохраните файл и запустите службу агента сервера 1С.

Разбираем мистику: Почему пароль "сам" меняется и учетка блокируется?

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

Причина 1: Политика паролей (Password Policy). В свойствах пользователя sa в MS SQL Server Management Studio (SSMS) по умолчанию могут стоять галочки "Требовать использование политики паролей" (Enforce password policy) или "Требовать смену пароля при следующем входе". Из-за этого срок действия пароля истекает (например, каждые 30 или 42 дня согласно политикам домена), учетная запись принудительно блокируется, и 1С вываливается с ошибкой Login failed. Для технологических учеток, под которыми работают службы и приложения, галочку истечения срока действия пароля (Enforce password expiration) необходимо снимать.

Причина 2: Блокировка учетной записи (Account Lockout). Ваш новый пароль абсолютно верный. Но учетная запись sa блокируется самим SQL-сервером из-за превышения числа попыток неудачного входа. Как это происходит? Вы поменяли пароль для базы 1С, но забыли, что под учеткой sa к этому же SQL-серверу подключаются:

• Скрипты резервного копирования (Maintenance Plans).
• Службы отчетов (Reporting Services).
• Другие сервисы в сети (например, WSUS или системы мониторинга).
• Тестовые или архивные базы 1С, запущенные на других серверах кластера.

Эти службы циклично "долбятся" в SQL со старым паролем. SQL видит множество неверных попыток входа и временно блокирует sa. В результате рабочая 1С с новым, правильным паролем тоже не может войти. Чтобы вычислить виновника, необходимо открыть логи MS SQL Server. Ищите ошибки MSSQLSERVER 18456 — в деталях сообщения будет указан IP-адрес или название приложения, с которого идут ошибочные запросы.

Правильная и безопасная схема ухода от sa (Best Practice)

Использовать sa для рабочих баз 1С — это грубое нарушение стандартов информационной безопасности. Учетная запись sa обладает абсолютными правами на весь экземпляр SQL Server. В случае компрометации злоумышленник получит доступ вообще ко всему. Мы рекомендуем полностью отказаться от нее для повседневной работы кластера 1С. Разберем по шагам правильный алгоритм перевода:

1. Откройте MS SQL Server Management Studio (SSMS) и авторизуйтесь под правами администратора.
2. В разделе Security -> Logins создайте нового пользователя (например, назовем его dbuser_1c).
3. Используйте метод аутентификации SQL Server, задайте сложный пароль. Снимите галочки Enforce password expiration (Требовать срок действия пароля), чтобы база не остановилась внезапно через месяц.
4. Перейдите на вкладку User Mapping. Выберите галочками только те информационные базы 1С, с которыми должен работать этот пользователь.
5. Для каждой выбранной базы в нижней панели назначьте роль db_owner. Важно: если сервер 1С должен сам создавать новые базы (например, при развертывании из конфигуратора), пользователю dbuser_1c также необходимо на вкладке Server Roles выдать роль dbcreator.
6. Теперь переходим в консоль кластера 1С. Открываем свойства информационных баз и меняем логин с sa на dbuser_1c, вводим новый пароль. Применяем изменения (если не применяется — используем способы, описанные выше).
7. Запускаем клиенты 1С и проверяем работу системы. Формируем тяжелые отчеты, проверяем проведение документов.
8. Только после успешного тестирования работы под новой учетной записью, мы возвращаемся в SSMS, открываем свойства sa, задаем ему сверхсложный сгенерированный пароль, и на вкладке Status переключаем Login в состояние Disabled.

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