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

Пароль пользователя 1С в клиент-серверном варианте хранится не в открытом виде, а внутри служебной таблицы v8users базы данных на SQL Server. Поэтому «классического» способа посмотреть забытый пароль не существует — можно только заменить хеш или пересоздать учётную запись. Задача решаема, но требует аккуратности: прямое вмешательство в таблицы информационной базы не поддерживается вендором и при ошибке способно вывести базу из строя.

Стандартный и самый безопасный путь — сброс через конфигуратор под другой учётной записью с полными правами. Однако на практике часто встречается ситуация, когда единственный администратор уволился, а его пароль никто не знает. Именно для такого случая существуют методы работы напрямую с SQL Server: очистка списка пользователей, правка таблицы Params и восстановление доступа через файл-снятие хеша.

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

Штатный сброс пароля через конфигуратор

Если в базе есть хотя бы один пользователь с полными правами и известным паролем, задача решается за минуту без всякого SQL. Откройте конфигуратор, авторизуйтесь под административной учётной записью и перейдите в меню Администрирование → Пользователи.

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

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

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

Когда штатный способ недоступен

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

Перед любыми действиями определите, где именно хранятся пользователи. В клиент-серверной базе список пользователей лежит внутри самой информационной базы (таблица v8users и связанные структуры), а не на уровне СУБД. Учётные записи SQL Server (sa, логины службы агента 1С) — отдельная история, их сброс выполняется средствами SQL Server Management Studio и к пользователям 1С отношения не имеет.

Аварийный сброс через таблицу Params

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

Откройте SQL Server Management Studio, подключитесь к серверу, найдите нужную базу и выполните запрос:

DELETE FROM [ИмяБазы].[dbo].[Params] WHERE [FileName] = 'users.usr';

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

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

Альтернатива: выгрузка и загрузка списка пользователей

Более мягкий вариант — не удалять запись, а предварительно сохранить её содержимое. Поле BinaryData в записи users.usr можно скопировать в отдельную таблицу или файл, что даст шанс вернуть исходный список, если что-то пойдёт не так. Однако редактировать двоичные данные «вручную» практически нереально, поэтому на практике чаще всё же удаляют запись и создают пользователей заново.

Сброс пароля администратора кластера и агента сервера 1С

Отдельная ситуация — когда утерян пароль не пользователя информационной базы, а администратора сервера 1С. Эти учётные записи хранятся в файлах каталога srvinfo на сервере приложений: 1CV8Clst.lst (администраторы кластера) и 1CV8Reg.lst (реестр кластера).

Чтобы сбросить администраторов кластера, остановите службу «Агент сервера 1С:Предприятия», сделайте копию каталога srvinfo, затем удалите или переименуйте файл 1CV8Clst.lst. После запуска службы список администраторов кластера станет пустым — консоль управления подключится без аутентификации, и вы сможете добавить администратора заново. Информационные базы и их пользователи при этом не затрагиваются.

Маршрут выбора метода

Проверка результата и типичные ошибки

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

Ограничения и безопасность

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

С точки зрения безопасности помните: любой, у кого есть права на запись в базу на SQL Server, может очистить список пользователей 1С и получить полный доступ к данным. Поэтому доступ к СУБД должен быть строго ограничен, а учётная запись, под которой работает агент сервера 1С, — иметь минимально необходимые права.

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