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

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

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

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

Как 1С хранит пароли в SQL-базе и почему метод работает

Платформа 1С:Предприятие не хранит пароли в открытом виде. Список пользователей информационной базы сериализуется во внутренний формат и сохраняется в таблице Params в поле BinaryData. Имя записи, отвечающей за список пользователей, обычно выглядит как users.1c — именно её платформа читает при запуске конфигуратора или предприятия.

Хеши паролей внутри этой структуры защищены необратимым преобразованием, поэтому «расшифровать» забытый пароль нельзя — можно только сбросить весь список целиком. Это принципиальное ограничение: восстановить конкретный старый пароль не получится ни одним штатным способом.

Если запись users.1c отсутствует, платформа считает базу «без пользователей» и разрешает вход в конфигуратор без аутентификации. На этом и построен весь метод сброса.

Подготовка: резервная копия и условия доступа

Для выполнения процедуры нужны две вещи: доступ к SQL Server с правами на изменение базы (логин с ролью db_owner на конкретную базу или sysadmin на сервере) и возможность временно остановить работу пользователей. Если доступа к SQL Server нет, сброс пароля базы невозможен — сначала придётся восстанавливать доступ к самой СУБД.

Перед любыми изменениями сделайте полную резервную копию базы через SQL Server Management Studio (SSMS): правый клик по базе → Tasks → Back Up → Full. Убедитесь, что файл копии реально создан и лежит в доступном месте. Это единственная страховка на случай ошибки в запросе.

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

Сброс пароля через запрос к таблице Params

Основной способ — удаление записи со списком пользователей. Откройте SSMS, подключитесь к серверу, выберите нужную базу и выполните запрос.

USE [ИмяБазы1С];
GO
-- Сначала смотрим, что есть в таблице
SELECT FileName FROM dbo.Params;
-- Удаляем запись со списком пользователей
DELETE FROM dbo.Params WHERE FileName = 'users.1c';

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

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

1. 1
   Сделайте полную резервную копию базы средствами SQL Server
2. 2
   Завершите активные сеансы пользователей через консоль кластера
3. 3
   Откройте SSMS и выполните SELECT FileName FROM dbo.Params, найдите запись списка пользователей
4. 4
   Выполните DELETE FROM dbo.Params WHERE FileName = 'users.1c'
5. 5
   Откройте конфигуратор 1С — вход должен выполниться без пароля
6. 6
   Создайте пользователей заново: Администрирование → Пользователи
7. 7
   Проверьте вход в режиме предприятия под новой учётной записью

Что делать после входа в конфигуратор

После сброса список пользователей пуст, и работать в базе пока нельзя — прикладные роли привязаны к учётным записям. Зайдите в раздел «Администрирование → Пользователи» и создайте как минимум одного пользователя с полными правами и ролью администратора, задайте ему надёжный пароль.

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

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

Альтернативные способы восстановления доступа

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

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

Третий путь — если база опубликована через сервер 1С и доступ к кластеру есть, можно временно поднять копию базы рядом, сбросить в ней пароль и перенести список пользователей. На практике это избыточно: прямой запрос к Params проще и быстрее.

Частые ошибки и как их избежать

Самая распространённая ошибка — выполнение DELETE FROM Params без условия WHERE. Это удалит все служебные параметры базы, включая служебные записи, необходимые для запуска, и база может перестать открываться. Всегда проверяйте условие фильтрации перед нажатием Execute.

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

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

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

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

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

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