В какой таблице SQL хранятся пользователи 1С

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

Точнее, в таблице dbo.Params есть запись, в которой в поле бинарных данных лежит сериализованный объект со списком пользователей информационной базы — их имена, хеши паролей, роли, настройки аутентификации. Извлечь эти данные обычным SELECT в читаемом виде нельзя: формат внутренний, закрытый и может меняться между версиями платформы.

Ниже разберём, как устроено хранение пользователей, что реально можно посмотреть через SQL, чем это опасно и какие безопасные способы получить список пользователей существуют.

Как 1С хранит пользователей в базе данных

Платформа 1С:Предприятие делит данные информационной базы на прикладные (справочники, документы, регистры) и служебные. Прикладные объекты маппируются на понятные таблицы: _Reference для справочников, _Document для документов, _InfoRg для регистров сведений и так далее. Служебная информация — настройки, параметры, список пользователей — хранится иначе.

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

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

Таблица Params: что внутри

Таблица dbo.Params присутствует в каждой базе 1С на SQL Server и имеет простую структуру: имя параметра (строка) и его значение (бинарные данные). Одна из записей содержит сериализованный список пользователей информационной базы. Посмотреть состав таблицы можно простым запросом:

SELECT [Name], DATALENGTH([BinaryData]) AS DataSize FROM dbo.Params;

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

Отдельно стоит таблица dbo._UsersWork (в некоторых версиях — с другим именем): в ней платформа ведёт технический учёт работы пользователей, но и она не является «таблицей учётных записей» — это рабочие данные сеансов, а не справочник логинов.

Почему нельзя править пользователей напрямую в SQL

Теоретически запись в Params можно изменить запросом UPDATE. На практике это почти гарантированно приводит к повреждению структуры хранения: сериализованный формат не документирован, контрольные данные не совпадут, и информационная база может перестать открываться или потерять список пользователей целиком.

Дополнительный риск — кластер серверов 1С кеширует параметры базы. Даже «удачная» правка может быть перезаписана работающим сервером или проявиться непредсказуемо после перезапуска служб.

Безопасные способы получить список пользователей

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

Программно список получают через встроенный язык — объект ПользователиИнформационнойБазы.ПолучитьПользователей(). Удобно оформить это как внешнюю обработку или выполнить через консоль кода, если она есть в конфигурации. Результат можно выгрузить в табличный документ или файл.

Для автоматизации используют пакетный режим конфигуратора или утилиты администрирования кластера (rac/ras) — они дают сведения о сеансах и активных пользователях. В типовых конфигурациях на БСП список пользователей справочника можно выгрузить обычным запросом или отчётом.

1. 1
   Откройте конфигуратор под учётной записью с правами администратора
2. 2
   Перейдите в меню «Администрирование → Пользователи»
3. 3
   Проверьте список: имена, роли, признаки аутентификации ОС
4. 4
   Если нужна выгрузка — используйте обработку с ПользователиИнформационнойБазы.ПолучитьПользователей()
5. 5
   Сверьте результат с активными сеансами в консоли кластера

Частая задача: сбросить пароль администратора через SQL

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

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

Как проверить результат и не навредить базе

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

Для регулярного контроля полезно периодически выгружать список пользователей штатными средствами и сравнивать с предыдущими версиями: так заметны несанкционированные учётные записи.

FAQ