Пользователи 1С в базе SQL Server: где лежат и что с ними можно делать

Список пользователей 1С в клиент-серверной базе лежит в служебной таблице Params, в записи с именем файла users.usr. Это сжатый двоичный блок, обычным SELECT его не прочитать. Отдельной таблицы «пользователи» с логинами и ролями в SQL Server нет.

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

Что и где хранится: карта таблиц

В базе 1С два разных понятия «пользователь». Их часто путают, а лежат они в разных местах.

Номера в именах _Reference… у каждой конфигурации свои. Угадывать их бесполезно: они меняются после обновления структуры.

Как проверить таблицу Params

Подключитесь к SQL Server через SSMS, выберите базу 1С и выполните:

SELECT FileName, DataSize, Modified
FROM Params
WHERE FileName = 'users.usr';

Вы увидите одну-две строки. Поле BinaryData содержит те самые закодированные данные. Расшифровывать их своими руками не нужно: платформа читает формат сама, а сторонние «парсеры» ломаются после каждого обновления платформы.

Как узнать имя таблицы справочника «Пользователи»

Сопоставление «объект 1С → таблица SQL» отдаёт сама платформа. Это штатный способ, он безопасен: ничего не пишет в базу.

1. Откройте базу в режиме Конфигуратор или под правами администратора с консолью кода.
2. Выполните в консоли запрос или код: ПолучитьСтруктуруХраненияБазыДанных().
3. В полученной таблице найдите строку, где в колонке «Метаданные» стоит Справочник.Пользователи.
4. Колонка «ИмяТаблицы» покажет имя вида _Reference…. Подставьте его в SQL.

Другой путь без кода: в Конфигураторе откройте меню «Администрирование» и найдите пункт с информацией о структуре хранения. Название пункта отличается в разных версиях, поэтому ищите его по слову «структура».

Почему Microsoft SQL Server не помощник в администрировании пользователей

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

Из этого следуют три практических вывода:

• любые «хитрые» запросы к Params не дадут вам списка пользователей, зато могут нарушить его целостность;
• права на уровне SQL (логин SQL Server, роль db_datareader) и права пользователя 1С никак не связаны: сервер 1С подключается к SQL одной учётной записью для всех сеансов;
• чтобы выяснить, кто что может в 1С, всегда проверяйте роли и группы доступа внутри самой программы.

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

Что нужно администратору по SQL на практике

Реальные задачи, где SQL всё же пригодится рядом с пользователями:

1. Подсчёт записей по автору. Таблицы документов содержат поле ссылки на пользователя. Запрос с GROUP BY покажет, кто создал больше всего документов за месяц.
2. Поиск «осиротевших» записей. LEFT JOIN документов к справочнику выявляет ссылки на несуществующих людей, если кто-то правил базу вручную.
3. Оценка размера. Сколько места занимает история входов и журнал изменений, и стоит ли их чистить.

Во всех трёх случаях запрос только читает данные. Как только появляется UPDATE или DELETE по таблицам пользователей, остановитесь и найдите штатный способ.

Поиск конкретного пользователя запросом

Когда имя таблицы известно, найти человека в справочнике просто. Пример для таблицы _Reference123 (подставьте свою):

SELECT _IDRRef, _Description, _Marked
FROM _Reference123
WHERE _Description LIKE N'%Иванов%';

Что вернётся:

• _IDRRef — внутренний идентификатор записи, двоичный;
• _Description — наименование, то есть ФИО;
• _Marked — пометка удаления (0x01 — помечен).

Названия остальных полей зависят от реквизитов справочника. Имена вида _Fld456 сопоставляются с реквизитами через ту же структуру хранения.

Чего этот запрос не покажет

Логин, роли и признак «пароль установлен» живут в users.usr, а не в справочнике. Поэтому по SQL вы увидите «Иванов И. И.» и не узнаете, под каким именем он входит. Связь между элементом справочника и пользователем базы держится на внутреннем идентификаторе, и просмотреть её можно только средствами 1С.

Группы доступа и участники групп

В конфигурациях с подсистемой «Управление доступом» участники групп хранятся в табличной части справочника «Группы доступа». Имя таблицы — отдельное, вида _Reference…_VT…. Найдите его так же, через структуру хранения: ищите строку Справочник.ГруппыДоступа.Пользователи.

Запрос состава группы в общем виде:

SELECT g._Description AS Группа, u._Description AS Пользователь
FROM _Reference45 g
JOIN _Reference45_VT46 m ON m._Reference45_IDRRef = g._IDRRef
JOIN _Reference123 u ON u._IDRRef = m._Fld47RRef
WHERE g._Description LIKE N'%Бухгалтер%';

Номера (45, 46, 47, 123) здесь условные. Подставляйте свои из структуры хранения.

Роли напрямую в этих таблицах не лежат. Профили и роли, назначенные пользователю базы, хранятся в users.usr. Через SQL их не прочитать, зато из 1С есть быстрый отчёт: в разделе администрирования откройте «Права доступа » и выберите «Отчёт по правам пользователей».

Отключить пользователя: как правильно

В SQL отключить пользователя 1С нельзя, потому что вход определяется данными из users.usr. Правка таблицы Params вручную превращает список пользователей в мусор. Результат: после следующего запуска никто не сможет войти, а восстановить можно только из резервной копии.

Работают три штатных способа.

Пример кода для отключения входа:

Пользователь = ПользователиИнформационнойБазы.НайтиПоИмени("ivanov");
Если Пользователь <> Неопределено Тогда
    Пользователь.АутентификацияСтандартная = Ложь;
    Пользователь.АутентификацияОС = Ложь;
    Пользователь.Записать();
КонецЕсли;

Историю этого пользователя в документах это не затрагивает: все документы остаются на месте, автор по-прежнему подставляется в реквизит «Ответственный».

Удаление пользователя и очистка ссылок

Удаление состоит из двух отдельных действий. Путать их нельзя.

1. Удаление пользователя информационной базы. Он перестаёт входить в 1С. Делается в Конфигураторе (список пользователей, кнопка «Удалить») или кодом: Пользователь.Удалить().
2. Удаление элемента справочника «Пользователи». Убирает ФИО из списков. Удалить можно, только если на элемент нет ссылок.

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

Что делать вместо этого:

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

Перед массовой очисткой сделайте выгрузку базы в .dt или бэкап SQL. Откат одной ошибки обойдётся в минуты, а восстановление потерянных ссылок — в дни.

Пароли и аутентификация: что лежит в базе

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

Практические следствия:

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

Кто и когда входил: активность и журнал

Для вопросов «кто сидит в базе прямо сейчас» и «кто вчера менял документ» SQL тоже ничего не даст.

Где искать:

• Активные пользователи. В 1С — «Администрирование» → «Активные пользователи». Там видны имя, компьютер, время начала сеанса и тип клиента. Для серверной базы то же показывает консоль кластера серверов.
• Журнал регистрации. Это отдельное хранилище: в каталоге 1Cv8Log рядом с данными кластера либо в базе формата .lgd. В SQL Server оно не лежит. Читать его надо через «Журнал регистрации» в 1С или через Конфигуратор.
• История изменений объектов. Включается отдельно и пишет в специальные таблицы базы. Подходит для документов и справочников, но не для входов.

Полезные отборы в журнале: событие «Сеанс. Аутентификация», событие «Сеанс. Ошибка аутентификации», нужный пользователь, период. Для расследования неудачных входов это основной источник.

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

Чек-лист: прежде чем лезть в SQL

Типичные ошибки

• Правка Params вручную. Повреждается список пользователей. Лечится восстановлением из копии.
• Угаданный номер таблицы. Номер _Reference123 в одной базе — это справочник «Номенклатура», а в другой — «Контрагенты». Всегда сверяйтесь со структурой хранения.
• DELETE из справочника. Остаются «битые» ссылки, часть форм перестаёт открываться.
• Запрос без ограничения по времени. Тяжёлый SELECT по табличной части без WHERE на 5–10 минут занимает ресурсы SQL Server.
• Сравнение по _Description. Разные люди могут иметь одинаковые ФИО. Для связки таблиц используйте _IDRRef.

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