Как сбросить пароли пользователей 1С, если база находится на SQL Server

Потеря пароля администратора или пользователя в клиент-серверной базе 1С — типовая ситуация, особенно когда учётные записи заводили давно и документирование не велось. В отличие от файлового варианта, где список пользователей хранится в файле 1Cv8.1CD, в клиент-серверном режиме данные о пользователях лежат в таблицах базы на SQL Server, а сама аутентификация может идти через кластер серверов 1С.

Есть три рабочих пути: штатный сброс через конфигуратор под другой учётной записью с правами администратора, операции через консоль управления кластером и прямое вмешательство в таблицы SQL Server. Первые два способа безопасны и рекомендованы, третий — аварийный вариант, когда штатные механизмы недоступны. Ниже разобраны все три сценария с условиями применения и рисками.

Перед любыми действиями сделайте резервную копию базы средствами SQL Server (полный backup) и зафиксируйте текущее состояние: версию платформы, имя информационной базы в кластере и имя базы данных на SQL Server. Это позволит откатиться, если что-то пойдёт не так.

Как устроено хранение пользователей в клиент-серверном варианте

В клиент-серверной архитектуре список пользователей информационной базы хранится внутри самой базы данных на SQL Server — в служебных таблицах, которые платформа создаёт при публикации базы. Основная таблица со списком пользователей и их свойствами называется v8users, а пароли хранятся в виде хэшей в таблице Params. Пароль в открытом виде нигде не сохраняется — восстановить его нельзя, можно только заменить или очистить.

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

Способ 1. Сброс пароля через конфигуратор под другим администратором

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

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

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

1. 1
   Войдите в конфигуратор под учётной записью с полными правами
2. 2
   Откройте Администрирование → Пользователи
3. 3
   Выберите нужного пользователя и задайте новый пароль
4. 4
   Сохраните и проверьте вход под новым паролем в тонком клиенте

Способ 2. Действия через консоль управления кластером 1С

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

Если утерян пароль администратора кластера, а список администраторов кластера пуст или недоступен, можно временно отключить проверку: остановите службу агента сервера 1С, найдите файл 1CV8Clst.lst в каталоге служебной информации кластера (обычно C:\Program Files\1cv8\srvinfo на Windows) и внесите изменения в соответствии с документацией платформы, затем запустите службу. После этого задайте нового администратора кластера через консоль.

Для сброса пароля администратора информационной базы откройте свойства базы в консоли кластера и измените параметры аутентификации администратора ИБ. Это не трогает данные в SQL Server напрямую и считается штатной операцией.

Способ 3. Аварийный сброс через таблицы SQL Server

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

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

Альтернативный приём — удалить все записи из таблицы v8users: после этого список пользователей пуст, и вход в конфигуратор выполняется без аутентификации. Минус подхода — теряются все настройки пользователей, роли и сопоставления, их придётся заводить заново. Поэтому предпочтительнее работать именно с Params, а таблицу пользователей не трогать.

-- Пример: просмотр списка пользователей
SELECT ID, Name, Descr FROM v8users;
-- Перед любыми DELETE/UPDATE сделайте:
BACKUP DATABASE [ИмяБазы] TO DISK = N'D:\backup\before_reset.bak';

Проверка результата после сброса

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

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

Типичные ошибки и ограничения

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

Вторая ошибка — попытка «узнать» старый пароль. Пароли хранятся только в виде хэшей, поэтому восстановление невозможно в принципе, доступен лишь сброс. Третья ошибка — работа без резервной копии: любой DELETE в служебных таблицах необратим, и восстановить данные можно только из backup.

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

Как выбрать подходящий способ

Выбор зависит от того, какой доступ у вас сохранился. Если есть вход под любым пользователем с полными правами — используйте только конфигуратор. Если доступа в базу нет, но есть административный доступ к серверу 1С — работайте через консоль кластера. Прямое вмешательство в SQL Server оставляйте на крайний случай.

Частые вопросы