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

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

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

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

Откройте Администрирование → Настройки пользователей и прав → Пользователи (в типовых конфигурациях на БП 3.0, ЗУП 3.1, УТ 11) или список пользователей в Конфигураторе через Администрирование → Пользователи. В карточке любого пользователя поля «показать пароль» нет — есть только флаг «Аутентификация 1С:Предприятия» и кнопка установки нового пароля.

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

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

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

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

Чем просмотр пароля отличается от восстановления доступа

Разделим две задачи, которые часто путают.

• 👁️ Посмотреть пароль — получить ту самую строку, которую пользователь вводит при входе. Штатно невозможно: в базе её нет.
• 🔑 Восстановить доступ — сделать так, чтобы под этим логином снова можно было войти. Решается заданием нового пароля. Старый при этом перестаёт действовать.

В 99% реальных ситуаций нужно именно второе. «Посмотреть» хотят по привычке, но практический результат — вход в базу — даёт только сброс. Поэтому дальше речь пойдёт о том, как корректно задать новый пароль, а не как «прочитать» старый.

Есть один честный нюанс: если пользователь сам где-то записал свой пароль (в менеджере паролей, в заметке), его можно узнать у него. Это не «просмотр в 1С», а обычное обращение к владельцу учётной записи — и самый быстрый путь, если человек на связи.

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

Как администратор задаёт новый пароль в режиме 1С:Предприятие

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

1. Войдите в программу под учётной записью с полными правами.
2. Откройте Администрирование → Настройки пользователей и прав → Пользователи.
3. Найдите нужного пользователя в списке, откройте его карточку двойным щелчком.
4. Нажмите кнопку установки пароля (в разных релизах подписана как Установить пароль или Сменить пароль) и введите новую строку дважды.
5. При необходимости снимите флаг Потребовать установку пароля при входе, если не хотите, чтобы пользователь сразу менял его сам.
6. Запишите изменения карточки.

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

Сброс пароля через Конфигуратор

Если в режиме 1С:Предприятие под администратором войти не получается (например, права настроены так, что список пользователей недоступен), но доступ к Конфигуратору есть, пароль задают там.

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

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

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

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

Что делать с клиент-серверной базой на SQL

В клиент-серверном варианте (сервер 1С:Предприятия + СУБД, например Microsoft SQL Server или PostgreSQL) появляется соблазн «залезть в SQL и вытащить пароль напрямую». Это не работает по той же причине: в таблице пользователей лежит хеш, а не пароль. Прочитав таблицу, вы увидите нечитаемую строку, из которой исходный пароль не восстанавливается.

Что действительно решается на уровне сервера — это ситуация, когда утерян пароль администратора кластера (не путать с паролем пользователя базы). Администратор кластера управляется в консоли администрирования или утилитой rac. Если забыт именно он:

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

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

Почему отладчик и «утилиты восстановления» не дают прочитать пароль

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

• 🔒 Отладчик не хранит паролей. В базе нет исходной строки, перехватывать на входе нечего — платформа оперирует хешем. Попытки «поймать» пароль через отладку чужого сеанса — это уже не администрирование, а вмешательство в чужой доступ, и с хешированием оно всё равно не даёт исходного пароля.
• 🚫 «Утилиты восстановления пароля» в лучшем случае делают то же, что Конфигуратор, — ставят новый пароль (тогда проще штатный путь), а в худшем это программы для подбора хеша. Подбор не «восстанавливает» пароль, а перебирает варианты, работает не всегда, нарушает политику безопасности и часто идёт в комплекте с нежелательным ПО.
• ⚖️ Доступ к чужой учётной записи без разрешения — это не технический приём, а вопрос прав и ответственности. Легальная задача администратора — вернуть доступ через сброс, а не раскрыть конкретный пароль сотрудника.

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

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

Чтобы проблема «забыли пароль» не повторялась, настройте процессы заранее.

• 🗂️ Резервное копирование . Регулярная выгрузка базы (.dt для файловой или средствами СУБД для серверной) — ваша страховка на случай утери пароля единственного администратора.
• 👥 Два администратора. Держите минимум две учётные записи с полными правами, желательно у разных людей. Тогда потеря одного пароля не блокирует управление базой.
• 🏢 Доменная аутентификация. В организации с Active Directory можно включить вход по учётной записи ОС — тогда отдельный пароль 1С пользователю не нужен, а доступом управляет администратор домена. Это снимает львиную долю обращений «забыл пароль от 1С».
• 📋 Политика паролей. В настройках пользователей и прав задайте минимальную длину и сложность пароля — это снижает число слабых и легко забываемых паролей. Не завышайте требования без нужды: слишком жёсткая политика провоцирует записки с паролем на мониторе.
• 🔁 Регламент передачи доступа. Опишите в инструкции, кто и по какой заявке сбрасывает пароли. Тогда восстановление доступа не будет каждый раз «пожарной» задачей, а превратится в понятную процедуру с фиксацией.

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