Каждый администратор баз данных 1С рано или поздно сталкивается с ситуацией, когда стабильно работающая система внезапно блокирует доступ для всех пользователей. Ошибка «Идентификация пользователя не выполнена» парализует работу предприятия: ни один сотрудник не может войти в базу, включая администратора системы, а попытка запустить Конфигуратор завершается аналогичным отказом. При этом сервер СУБД и сам сервер приложений 1С функционируют в штатном режиме, а другие базы данных могут работать без нареканий.
В такой ситуации стандартные методы администрирования — очистка локального кэша пользователей, перезапуск служб 1С:Предприятия или даже полная перезагрузка физического сервера — не приносят результатов. Восстановление базы данных из резервной копии (бэкапа) является самым очевидным решением, но оно неизбежно ведет к потере документов и операций, введенных с момента создания последнего бэкапа. В этой статье мы подробно разберем, как устроена система авторизации 1С на физическом уровне СУБД, и рассмотрим детальные алгоритмы восстановления доступа без потери актуальных данных.
Для того чтобы эффективно бороться с проблемой, мы должны понимать внутреннее устройство механизмов безопасности платформы 1С:Предприятие 8. Список пользователей и параметры их учетных записей хранятся непосредственно внутри структуры таблиц базы данных в СУБД (будь то Microsoft SQL Server, PostgreSQL, IBM DB2 или Oracle). Основную роль здесь играют два элемента структуры:
v8users — это системная таблица платформы, которая содержит плоский список всех зарегистрированных учетных записей пользователей информационной базы. Здесь хранятся их идентификаторы (GUID), уникальные имена, а также базовые параметры сопоставления.Params — системная таблица параметров базы данных. В ней содержится критически важная запись, где в поле FileName указано имя бинарного файла настроек users.usr. Именно внутри этого файла в зашифрованном виде хранятся хэши паролей пользователей, их роли, права доступа и настройки безопасности.В старых версиях платформы 1С (до линейки 8.3) для полного сброса списка пользователей было достаточно просто очистить или удалить таблицу v8users. Однако на современных релизах платформы (начиная с 8.3.15 и новее) такой прямолинейный подход вызывает нарушение логической целостности базы данных. Если очистить таблицу v8users, но оставить нетронутым файл users.usr в таблице Params, при попытке открыть Конфигуратор платформа выдаст критическую ошибку и завершит работу. Поэтому мы должны воздействовать на обе таблицы синхронно.
Рассмотрим наиболее надежный и проверенный метод сброса авторизации для клиент-серверных баз, работающих под управлением Microsoft SQL Server. Суть метода заключается во временном скрытии информации о пользователях. Платформа сочтет базу абсолютно «пустой» (новой) и позволит войти в Конфигуратор без пароля. После этого мы вернем пользователей на место прямо «на лету» и зададим новые учетные данные администратора.
Разберем этот процесс по шагам:
v8users во временную таблицу v8users_old, а также изменит имя файла настроек авторизации в таблице Params на users.usr_old:
USE [Имя_Вашей_Базы]
GO
EXEC sp_rename 'v8users', 'v8users_old'
GO
UPDATE [Params] SET [FileName] = 'users.usr_old' WHERE [FileName] = 'users.usr'
GO
Важное примечание: не закрывайте среду SQL Server Management Studio и окно с запросами после выполнения этого шага!
v8users и файла users.usr, она решит, что в базе нет ни одного пользователя, и откроет конфигурационную среду без запроса имени и пароля.v8users. Мы должны удалить эту пустую таблицу и вернуть нашей старой таблице v8users_old ее первоначальное имя, а также вернуть имя файлу настроек авторизации. Выполним следующий SQL-запрос:
USE [Имя_Вашей_Базы]
GO
DROP TABLE [v8users]
GO
EXEC sp_rename 'v8users_old', 'v8users'
GO
UPDATE [Params] SET [FileName] = 'users.usr' WHERE [FileName] = 'users.usr_old'
GO
После выполнения этих действий мы можем закрыть Конфигуратор и спокойно запустить рабочие сеансы пользователей. Доступ к базе полностью восстановлен, и при этом ни один документ, введенный в течение рабочего дня, не пострадал.
Если наша клиент-серверная база 1С развернута на СУБД PostgreSQL, общий алгоритм действий остается точно таким же, однако синтаксис SQL-запросов будет отличаться в соответствии с требованиями этой СУБД. Проанализируем команды для утилиты pgAdmin или консольного клиента psql.
Для переименования объектов на первом этапе выполним следующий запрос:
-- Переименовываем таблицу пользователей
ALTER TABLE v8users RENAME TO v8users_old;
-- Изменяем имя файла настроек авторизации в таблице параметров
UPDATE params SET filename = 'users.usr_old' WHERE filename = 'users.usr';
После этого мы открываем Конфигуратор 1С без ввода учетных данных. Затем, не закрывая Конфигуратор, возвращаемся в консоль PostgreSQL и выполняем запрос на восстановление исходной структуры данных:
-- Удаляем пустую таблицу, созданную платформой при запуске Конфигуратора
DROP TABLE v8users;
-- Возвращаем старую таблицу на место
ALTER TABLE v8users_old RENAME TO v8users;
-- Восстанавливаем ссылку на оригинальный файл настроек пользователей
UPDATE params SET filename = 'users.usr' WHERE filename = 'users.usr_old';
Далее мы возвращаемся в Конфигуратор, переходим в список пользователей, меняем пароль администратора и сохраняем изменения. Метод работает безотказно и исключает потерю рабочих данных.
Иногда повреждается только сама таблица v8users или бинарное содержимое настроек авторизации в таблице Params (например, из-за сбоя транзакции СУБД или повреждения дискового сектора). Если у нас есть вчерашний бэкап этой же базы, нам нет необходимости полностью перезаписывать им рабочую базу. Мы можем перенести только те таблицы, которые отвечают за авторизацию пользователей.
Рассмотрим пошагово, как реализовать этот перенос в MS SQL Server:
[Temp_Backup_DB]).v8users в рабочей базе данных и скопирует в нее записи из бэкапа:
USE [Rabochaya_DB]
GO
-- Очищаем текущую таблицу пользователей
DELETE FROM [Rabochaya_DB].[dbo].[v8users]
GO
-- Копируем данные из бэкапа
INSERT INTO [Rabochaya_DB].[dbo].[v8users]
SELECT * FROM [Temp_Backup_DB].[dbo].[v8users]
GO
users.usr из резервной копии:
USE [Rabochaya_DB]
GO
-- Обновляем бинарные данные настроек пользователей
UPDATE [Rabochaya_DB].[dbo].[Params]
SET [BinaryData] = (SELECT [BinaryData] FROM [Temp_Backup_DB].[dbo].[Params] WHERE [FileName] = 'users.usr')
WHERE [FileName] = 'users.usr'
GO
После выполнения этого запроса мы восстановим структуру пользователей на состояние вчерашнего дня. Все транзакции, документы и справочники, созданные в рабочей базе сегодня, останутся абсолютно нетронутыми. Мы сможем войти в систему под старыми паролями.
Выясним основные причины, по которым пользователи могут внезапно столкнуться с ошибкой «Идентификация пользователя не выполнена». Понимание этих факторов поможет системным администраторам предотвратить подобные сбои в будущем.
rphost мог аварийно завершить запись в транзакцию авторизации, из-за чего хэши паролей повреждались. Решением является регулярное обновление платформы до стабильных LTS-релизов и обновление компонентов SQL Native Client / OLE DB Driver на сервере.USR1CV8), или некорректная настройка протокола Kerberos.v8users или Params, платформа не сможет прочитать данные авторизации. Для диагностики мы рекомендуем регулярно запускать проверку целостности базы данных СУБД средствами SQL:
DBCC CHECKDB ('Имя_Вашей_Базы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO
Для предотвращения подобных критических ситуаций мы советуем придерживаться нескольких простых правил администрирования:
Применяя описанные нами методы сброса авторизации через СУБД, вы сможете оперативно вернуть систему к жизни, сэкономить рабочее время сотрудников организации и гарантировать полную сохранность коммерческой информации.