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

← На главную

Каждый системный администратор или разработчик 1С хотя бы раз в жизни сталкивался с ситуацией, когда из-за неосторожных действий, сбоя при обновлении или некорректной работы скриптов база данных оставалась без единого пользователя с правами администрирования. В этот момент конфигурация становится заблокированной для любых изменений, а зайти под полными правами не представляется возможным. Для предотвращения таких инцидентов и контроля изменений в составе администраторов можно применить инструмент для периодического сравнения профилей безопасности и ролей пользователей.

В рамках этой статьи мы подробно разберем, как устроен механизм авторизации платформы 1С на уровне СУБД, проанализируем "трюк" с временным скрытием таблиц пользователей и рассмотрим готовые решения для СУБД MS SQL Server и PostgreSQL, а также для файловых баз данных. Мы научимся восстанавливать доступ безопасно, не теряя уникальные идентификаторы (UUID) существующих пользователей и не нарушая ссылочную целостность базы данных.

Анатомия авторизации 1С: где хранятся пользователи?

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

Таблица v8users — в ней хранятся записи обо всех пользователях информационной базы, включая их уникальные идентификаторы (UUID), имена, хэши паролей и другие настройки.
Запись в таблице системных настроек Params — запись с уникальным именем файла users.usr, которая дублирует информацию о структуре пользователей и сообщает платформе, что в базе включена авторизация.

Когда мы пытаемся открыть Конфигуратор, платформа делает запрос к СУБД. Если таблица v8users пуста или отсутствует, а записи users.usr в Params нет, 1С считает, что база абсолютно "чистая" и в ней еще не создано ни одного пользователя. В этом случае система автоматически предоставляет монопольный административный доступ любому, кто запускает Конфигуратор.

Если же мы просто удалим таблицу v8users или очистим ее содержимое, мы действительно сможем войти в систему. Однако при этом мы безвозвратно потеряем всех существующих пользователей. Нам придется создавать их заново, из-за чего изменятся их внутренние идентификаторы (UUID). Как результат — собьется история работы пользователей, привязка к авторам документов и настройки прав. Наша задача — обойти эту проблему элегантно.

Решение для MS SQL Server: пошаговый алгоритм

Рассмотрим самый надежный способ восстановления прав для баз, работающих под управлением Microsoft SQL Server. Этот способ заключается во временном "сокрытии" пользователей, входе в Конфигуратор и мгновенном их возвращении на место до сохранения изменений.

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

Шаг 2. Временное переименование таблиц. Нам необходимо заставить 1С поверить, что пользователей в базе нет. Для этого запустим SQL Server Management Studio (SSMS), откроем новое окно запроса к нашей базе данных и выполним следующий скрипт:


USE [Имя_Вашей_Базы]
GO
-- Переименовываем таблицу пользователей во временное имя
EXEC sp_rename 'v8users', 'v8users_tmp'
GO
-- Скрываем запись о наличии пользователей в системной таблице Params
UPDATE [Params] SET [FileName] = 'users.usr_tmp' WHERE [FileName] = 'users.usr'
GO

Шаг 3. Вход в Конфигуратор. Теперь запустим 1С:Предприятие в режиме "Конфигуратор". Поскольку платформа не обнаружила таблицу v8users и запись users.usr, вход произойдет мгновенно, без запроса имени пользователя и пароля. Вы получите полные права.

КРИТИЧЕСКИ ВАЖНО: Ни в коем случае не закрывайте Конфигуратор и не открывайте список пользователей на этом этапе! Оставьте окно Конфигуратора открытым и вернитесь в среду SSMS.

Шаг 4. Восстановление таблиц обратно. Теперь, когда сессия Конфигуратора уже открыта с максимальными правами, нам нужно вернуть реальных пользователей на место, чтобы не нарушить структуру базы. Для этого в SSMS выполним обратный скрипт:


USE [Имя_Вашей_Базы]
GO
-- Удаляем пустую таблицу v8users, которую 1С могла создать при входе
IF OBJECT_ID('v8users', 'U') IS NOT NULL
    DROP TABLE [v8users]
GO
-- Возвращаем нашей оригинальной таблице пользователей ее исходное имя
EXEC sp_rename 'v8users_tmp', 'v8users'
GO
-- Восстанавливаем системную запись в таблице Params
UPDATE [Params] SET [FileName] = 'users.usr' WHERE [FileName] = 'users.usr_tmp'
GO

Шаг 5. Назначение роли администратора. Вернемся в открытый Конфигуратор. Перейдем в меню Администрирование — Пользователи. В этот момент платформа обратится к уже восстановленной таблице v8users, и перед нами появится весь список наших реальных пользователей со старыми UUID.

Найдем нужного пользователя, откроем его свойства, перейдем на вкладку Прочие и установим флажок напротив роли с административными правами (например, "Полные права" или "Администратор системы"). Сохраним изменения. Теперь можно закрыть Конфигуратор и зайти в базу под своим привычным пользователем.

Решение для СУБД PostgreSQL

Если ваша информационная база развернута на СУБД PostgreSQL, общий алгоритм действий остается точно таким же, однако синтаксис SQL-запросов будет отличаться. Для работы используйте утилиту pgAdmin или консольный клиент psql.

Разберем по шагам SQL-команды для PostgreSQL.

Для скрытия пользователей (выполняем перед запуском Конфигуратора):


-- Переименовываем таблицу пользователей
ALTER TABLE v8users RENAME TO v8users_tmp;

-- Скрываем системный файл настроек пользователей
UPDATE Params SET FileName = 'users.usr_tmp' WHERE FileName = 'users.usr';

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


-- Удаляем автоматически созданную пустую таблицу пользователей (если она появилась)
DROP TABLE IF EXISTS v8users;

-- Возвращаем исходную таблицу пользователей на место
ALTER TABLE v8users_tmp RENAME TO v8users;

-- Восстанавливаем системную запись в таблице Params
UPDATE Params SET FileName = 'users.usr' WHERE FileName = 'users.usr_tmp';

После выполнения этих запросов переходим в меню управления пользователями в Конфигураторе и назначаем необходимые роли.

Что делать, если база файловая (.1CD)?

В файловом варианте работы у нас нет прямого доступа к SQL-консоли, однако решить проблему также возможно. Для этого существует два основных пути.

Способ 1. Использование специализированного софта

В сообществе разработчиков популярно использование специализированных утилит (например, с открытым исходным кодом, таких как PasswordChanger1C или классического инструмента Tool_1CD). Эти программы позволяют напрямую открыть файл базы данных 1Cv8.1CD, прочитать бинарные данные таблицы v8users и сбросить хэш пароля администратора или назначить нужную роль конкретному пользователю буквально в один клик.

Способ 2. Ручное редактирование файла базы данных через HEX-редактор

Этот способ требует максимальной осторожности и обязательного создания резервной копии файла 1Cv8.1CD.

Откроем копию базы данных в любом HEX-редакторе (например, WinHex, HxD).
Выполним поиск текстовой строки users.usr в кодировке Unicode.
Для того чтобы платформа перестала видеть эту запись, достаточно заменить один символ в названии файла прямо внутри бинарного кода (например, переименовать в users.us_).
Затем выполним поиск строки V8USERS в кодировке ASCII и также заменим одну букву (например, на H8USERS).
Сохраним изменения и запустим Конфигуратор. Платформа пустит нас без пароля.
Не закрывая Конфигуратор, вернем измененные символы обратно в HEX-редакторе и сохраним файл.
В Конфигураторе зайдем в список пользователей и восстановим необходимые права.

Альтернативный вариант: Использование привилегированного режима

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

Для этого в обработке необходимо использовать метод УстановитьПривилегированныйРежим(Истина), который отключает проверку прав доступа на уровне платформы. Пример программного кода для добавления роли пользователю выглядит следующим образом:


&НаСервере
Процедура ВосстановитьПраваНаСервере()
    
    УстановитьПривилегированныйРежим(Истина);
    
    // Находим нужного пользователя информационной базы по имени
    ИскомыйПользователь = ПользователиИнформационнойБазы.НайтиПоИмени("Администратор");
    
    Если ИскомыйПользователь <> Неопределено Тогда
        // Находим роль, которую необходимо добавить
        РольАдминистратора = Метаданные.Роли.ПолныеПрава;
        
        // Проверяем, добавлена ли уже эта роль
        Если Не ИскомыйПользователь.Роли.Содержит(РольАдминистратора) Тогда
            ИскомыйПользователь.Роли.Добавить(РольАдминистратора);
            ИскомыйПользователь.Записать();
            Сообщить("Административные права успешно восстановлены для пользователя!");
        КонецЕсли;
    КонецЕсли;
    
КонецПроцедуры

Однако этот способ сработает только в том случае, если у текущего авторизованного пользователя есть права на исполнение внешнего кода. В большинстве случаев при полной потере администрирования этот метод недоступен, и приходится прибегать к манипуляциям на уровне СУБД.

Действительно ли 1С блокирует удаление "последнего админа"?

В ходе обсуждения на форумах часто возникает вопрос: "Правда ли, что платформа 1С не позволит оставить базу совсем без администраторов?".

Выясним реальное положение дел:

При интерактивной работе: Если вы попытаетесь вручную в Конфигураторе удалить единственного пользователя с правами администрирования или снять с него флажок полной роли, платформа выдаст предупреждение: "После исполнения в списке не осталось бы ни одного пользователя с административными правами!" и заблокирует операцию.
При обновлении конфигурации: Если разработчик в процессе доработки конфигурации случайно удалил саму роль (например, роль ПолныеПрава была удалена из дерева объектов метаданных или в ней была снята галочка "Администрирование"), то при обновлении базы данных конфигурации (нажатии клавиши F7) все пользователи, у которых была эта роль, мгновенно и безвозвратно теряют права администратора. Платформа далеко не во всех версиях успевает отследить этот логический тупик.
При программном изменении: При выполнении некорректно написанного обмена данными или групповой обработки изменения пользователей через объект ПользовательИнформационнойБазы, проверки платформы можно легко обойти, оставив базу без действующих администраторов.

Превентивные меры: штатное восстановление доступа

Начиная с версии платформы 8.3.15.2107, разработчики 1С добавили штатную возможность настройки восстановления паролей. Чтобы обезопасить себя от подобных ситуаций в будущем, рекомендуем заранее настроить эту функцию в параметрах информационной базы.

В режиме "1С:Предприятие" администратор может указать адрес электронной почты для каждого пользователя и настроить SMTP-сервер для отправки системных сообщений. В случае утери доступа на форме авторизации появится ссылка "Забыли пароль?", перейдя по которой пользователь сможет получить одноразовый код восстановления доступа на свой e-mail. Это цивилизованный и безопасный способ, который исключает необходимость прямого вмешательства в таблицы СУБД.