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

Ошибка входа в информационную базу после увольнения единственного администратора — типичный случай для связки 1С и PostgreSQL: логины хранятся в системной таблице v8users на сервере СУБД, и при пустом списке пользователей в конфигураторе доступ восстанавливается только напрямую через запросы к этой таблице. Метод отработан на практике и подходит для клиент-серверного варианта работы, но требует осторожности: правка служебных данных в обход платформы при неграмотном обращении способна повредить базу, поэтому перед изменениями обязательно делается резервная копия.

Важно понимать различие двух уровней паролей. Пароль пользователя PostgreSQL (например, роли, под которой сервер 1С подключается к СУБД) и пароль пользователя информационной базы 1С — это разные вещи. Первый меняется средствами самой СУБД через psql или pgAdmin. Второй хранится внутри таблиц базы в зашифрованном виде и меняется либо через конфигуратор, либо прямой правкой таблицы v8users. Ниже разобраны оба сценария.

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

Как устроено хранение пользователей 1С в PostgreSQL

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

Структура поля Data недокументирована и отличается между версиями платформы. Именно поэтому универсальный приём — не разбирать содержимое поля, а подменить его целиком на заведомо рабочий эталон: содержимое Data от пользователя с известным (или пустым) паролем, созданного в тестовой базе на той же версии платформы. Это ключевое ограничение метода, о котором часто забывают.

Подготовка: бэкап и доступ к СУБД

Для работы понадобится доступ к серверу PostgreSQL с правами суперпользователя или владельца базы. Обычно это роль postgres либо роль, под которой работает сервер 1С. Подключиться можно через psql на самом сервере или через pgAdmin с рабочей станции, если сетевой доступ к СУБД открыт.

Резервную копию делайте средствами pg_dump в момент, когда пользователи не работают. Логический дамп одной базы создаётся одной командой и позволяет восстановить данные в исходное состояние, если правка пойдёт не так. Останавливать сервер 1С для дампа не обязательно, но желательно исключить активные сеансы, чтобы не зафиксировать промежуточное состояние данных.

pg_dump -U postgres -F c -f /backup/infobase_$(date +%F).dump имя_базы

Дополнительно полезно выгрузить текущее содержимое таблицы v8users в отдельный файл. Это позволит вернуть конкретную запись пользователя без восстановления всей базы, если потребуется откатить только изменение пароля.

Способ 1: подмена поля Data на эталонное значение

Самый контролируемый метод — заменить содержимое поля Data у нужного пользователя на значение от пользователя с известным паролем. Для этого заранее создают эталон: в пустой тестовой базе на той же версии платформы заводят пользователя, например «Администратор», с пустым паролем и полными правами, а затем выгружают его запись из v8users.

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

1. 1
   Сделайте резервную копию базы средствами pg_dump
2. 2
   Подключитесь к базе: psql -U postgres -d имя_базы
3. 3
   Найдите пользователя: SELECT "ID", "Name" FROM v8users;
4. 4
   Обновите запись: UPDATE v8users SET "Data" = '<эталонное значение>' WHERE "ID" = '<id пользователя>';
5. 5
   Откройте конфигуратор под этим пользователем с пустым паролем
6. 6
   Задайте новый пароль через Администрирование → Пользователи

Обратите внимание на кавычки в запросах: имена полей в таблицах 1С регистрозависимые, поэтому их следует заключать в двойные кавычки. Запрос без кавычек к полю Data или ID завершится ошибкой, и это одна из самых частых причин «неработающей» инструкции.

Способ 2: очистка списка пользователей и создание администратора заново

Если эталонного значения под рукой нет, применяют более грубый приём: полностью очищают таблицу v8users. После очистки информационная база считается базой без единого пользователя, и конфигуратор открывается без запроса пароля. Дальше через меню «Администрирование — Пользователи» создают нового администратора с полными правами и задают ему пароль.

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

DELETE FROM v8users;

Поэтому полная очистка оправдана, когда база небольшая, пользователей мало, а эталонное значение Data получить неоткуда. В крупных базах с настроенным разграничением прав предпочтителен точечный сброс одного администратора по первому способу.

Способ 3: сброс пароля роли PostgreSQL

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

Подключитесь к PostgreSQL под суперпользователем (на Linux обычно через sudo -u postgres psql, когда разрешена локальная аутентификация peer) и выполните команду ALTER ROLE с новым паролем. После этого новый пароль нужно указать в свойствах информационной базы в консоли кластера серверов 1С или при регистрации базы — иначе сервер 1С продолжит обращаться со старыми учётными данными и подключение не восстановится.

ALTER ROLE имя_роли WITH PASSWORD 'НовыйПароль';

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

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

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

Что выбрать в вашей ситуации

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

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

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