Потерян пароль администратора сервера 1С: как вернуть доступ

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

Второй момент, из-за которого теряют время: под «паролем сервера 1С» понимают три разные вещи. Пароль администратора кластера, пароль администратора СУБД (PostgreSQL, MS SQL, Db2) и пароль пользователя информационной базы с правами администратора — это три независимых секрета, и сбрасываются они по-разному. Ниже разберём каждый, с путями и командами для Windows и Linux.

Какой пароль вы потеряли — определите точно

От ответа зависит всё дальнейшее. Признаки:

• 🔐 Администратор кластера. Консоль администрирования или rac не пускают к кластеру, просят имя и пароль администратора. Секрет лежит в реестре кластера на сервере.
• 🗄️ Администратор СУБД. База не стартует, в журнале регистрации — ошибка подключения к СУБД, неверный логин/пароль пользователя базы данных. Секрет лежит в самой СУБД.
• 👤 Пользователь информационной базы. 1С:Предприятие запускается, но не принимает пароль конкретного пользователя. Это пароль внутри базы, к серверу он отношения не имеет и сбрасывается в Конфигураторе — здесь мы его не рассматриваем.

Восстановление пароля администратора кластера серверов

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

Единственный безопасный путь — восстановить файл реестра из резервной копии, снятой до того, как пароль был задан или изменён. Ручная правка 1CV8Clst.lst в работающей системе легко ломает весь кластер, поэтому её не делаем.

Где лежит реестр:

• Windows — рабочий каталог агента, обычно C:\Program Files\1cv8\srvinfo. Внутри — подкаталог вида reg_1541 (по номеру порта менеджера кластера), в нём 1CV8Clst.lst.
• Linux — каталог данных сервера, по умолчанию домашний каталог служебного пользователя (например, /home/usr1cv8/.1cv8/1C/1cv8), далее тот же reg_1541/1CV8Clst.lst.

Точный путь задаётся параметром -d при запуске агента (ragent), поэтому на вашем сервере каталог может отличаться — ориентируйтесь на параметры службы.

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

Порядок действий:

1. Предупредите пользователей и дождитесь, пока все выйдут из баз этого кластера.
2. Остановите службу агента сервера. На Windows это служба с названием вида Агент сервера 1С:Предприятия 8.3 (в оснастке services.msc). На Linux — systemctl stop srv1cv83.
3. Скопируйте текущий srvinfo целиком в сторону — на случай, если понадобится вернуться.
4. Положите на место 1CV8Clst.lst (а лучше весь каталог reg_1541) из резервной копии.
5. Запустите службу агента снова и войдите в консоль администрирования под восстановленным администратором.

Чего делать не нужно: не пересоздавайте кластер, не удаляйте информационные базы и не сносите каталог srvinfo целиком. Потеря пароля администратора — не повод терять базы.

Сброс пароля администратора СУБД

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

PostgreSQL

1. Найдите файл pg_hba.conf в каталоге данных кластера PostgreSQL (на Windows — C:\Program Files\PostgreSQL\<версия>\data, на Linux — /etc/postgresql/<версия>/main/ или /var/lib/pgsql/data/).
2. Временно смените метод аутентификации для локальных подключений на trust. В строке локального доступа это выглядит так:

# было:  local   all   all   scram-sha-256
# стало: local   all   all   trust

3. Перезапустите службу PostgreSQL.
4. Подключитесь без пароля и задайте новый:

ALTER USER postgres WITH PASSWORD 'новый_надёжный_пароль';

5. Верните в pg_hba.conf прежний метод (scram-sha-256 или md5) и снова перезапустите службу.

Microsoft SQL Server

Проще всего, если учётная запись Windows входит в роль sysadmin: войдите в SQL Server Management Studio через проверку подлинности Windows, откройте Безопасность → Имена входа → sa → Свойства и задайте новый пароль.

Если администраторского доступа нет совсем, запустите экземпляр в однопользовательском режиме (параметр запуска -m в диспетчере конфигурации SQL Server), подключитесь через sqlcmd и выполните:

ALTER LOGIN sa WITH PASSWORD = 'новый_пароль';
ALTER LOGIN sa ENABLE;

После этого уберите параметр -m и перезапустите экземпляр в обычном режиме. Перезапуск разрывает все подключения — делайте это в окно обслуживания.

IBM Db2

Db2 по умолчанию проверяет подлинность не своими, а операционными учётными записями. То есть «пароль СУБД» здесь — это пароль пользователя ОС, под которым 1С подключается к Db2. Сбросьте пароль этой учётной записи средствами операционной системы (на Linux — passwd <пользователь>, на Windows — через управление учётными записями), а затем укажите его в свойствах базы.

Пропишите новый пароль в свойствах базы

Сброса в СУБД мало — 1С должна знать новый пароль. В консоли администрирования серверов:

1. Разверните сервер → Информационные базы.
2. Откройте свойства нужной базы правой кнопкой → Свойства.
3. В полях пользователя и пароля сервера баз данных впишите актуальные значения и сохраните.

Для автоматизации то же делают утилитой rac, но набор параметров зависит от версии — смотрите rac help infobase.

Важная тонкость: 1С подключается к СУБД не обязательно под суперпользователем. Если при создании базы указали отдельную учётную запись (например, свою роль в PostgreSQL вместо postgres), сбрасывать нужно пароль именно этой учётной записи, а не только суперпользователя. Какой пользователь прописан в базе, видно в тех же свойствах информационной базы в поле пользователя сервера баз данных.

Восстановление доступа через резервную копию

Резервная копия выручает в двух разных ситуациях, и важно не перепутать, что именно восстанавливать:

Отсюда вывод: восстановление из бэкапа помогает с паролем кластера, но не с паролем СУБД. Выгрузка .dt или копия файлов базы данных пароль администратора СУБД в себе не несут — его всё равно придётся сбрасывать способами из предыдущего раздела.

Что делать опытному администратору: командная строка и её пределы

Для управления кластером из командной строки есть утилита rac (работает через сервер администрирования ras). Ей удобно скриптовать рутину:

rac cluster list
rac session list --cluster=<идентификатор кластера>

Полный список команд и параметров выдаёт rac help — не угадывайте флаги, сверяйтесь со справкой.

Но есть принципиальное ограничение. Если список администраторов кластера задан, rac потребует их логин и пароль ровно так же, как консоль. Командная строка не обходит защиту — она ею пользуется. Поэтому при утраченном пароле администратора кластера rac не поможет: остаётся только восстановление реестра из копии (см. выше).

Напомню про архитектуру, чтобы не искать проблему не там. Клиент и консоль обращаются к агенту сервера (порт 1540), агент — к менеджеру кластера (порт 1541), рабочие процессы слушают диапазон портов, заданный в свойствах рабочего сервера. Ошибка «нет администратора кластера» приходит от агента и к СУБД отношения не имеет — не тратьте время на перезапуск PostgreSQL, если проблема в доступе к консоли.

Как больше не терять пароли сервера

Потеря пароля администратора кластера — почти всегда следствие того, что его задали один раз при установке и нигде не записали.

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

Ошибки, из-за которых сброс не помогает

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

• 🔁 Сбросили пароль суперпользователя, а база ходит под другой учёткой. Поменяли postgres, а в свойствах базы прописан отдельный пользователь — ошибка подключения осталась. Сверяйте имя пользователя в свойствах базы перед сбросом.
• 🏷️ Перепутали администратора кластера и администратора базы. Восстанавливают реестр srvinfo, хотя 1С:Предприятие запускается и просит пароль конкретного пользователя. Это внутренний пароль базы, реестр сервера тут ни при чём.
• ⏰ Остановили службу агента среди рабочего дня. Все пользователи вылетели из всех баз кластера, а не только из проблемной. Останавливать агент нужно в окно обслуживания.
• ✍️ Правили 1CV8Clst.lst вручную. Текстовый на вид файл имеет жёсткую структуру; ошибка в нём роняет весь кластер. Не редактируйте его — только заменяйте копией целиком.
• 🔓 Забыли вернуть pg_hba.conf. Оставили trust «на всякий случай» — и получили СУБД, открытую без пароля. Возвращайте прежний метод сразу после смены пароля.

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