Проблема, когда установленные пароли пользователей в 1С:Предприятие внезапно перестают приниматься системой, является одной из самых неприятных для системного администратора. Ситуация выглядит парадоксально: пароль точно не менялся, администратор заново устанавливает тот же самый набор символов, и пользователь временно получает доступ, но через неделю или две проблема повторяется. В рамках данной статьи мы подробно разберем, почему это происходит, и проанализируем технические способы устранения этого бага.
Прежде чем переходить к глубокому техническому анализу таблиц базы данных, нам необходимо убедиться, что исключены базовые причины. Разберем по шагам, что нужно проверить в первую очередь:
Одной из наиболее вероятных причин сбоя аутентификации является так называемое «демоническое» (динамическое) обновление. Рассмотрим механизм возникновения ошибки: при обновлении конфигурации без остановки работы пользователей кэш на сервере 1С может рассинхронизироваться с данными в базе.
Параметры пользователей и их хэши паролей могут «зависнуть» в старой версии кэша. В этом случае, даже если в базе данных всё корректно, сервер приложений 1С обращается к устаревшим данным в памяти. Чтобы решить эту проблему, выполним следующие действия:
1C:Enterprise 8 Server Agent.srvinfo (обычно в C:\Program Files\1cv8\srvinfo).snrg и reg_1541.Этот метод позволяет полностью обновить кэш метаданных и часто решает проблемы с «пропадающими» паролями без изменения самих данных. Для упрощения задачи можно использовать батник для очистки кэша 1С.
Если проблема сохраняется, нам нужно спуститься на уровень хранения данных в SQL-сервере. Данные пользователей в 1С хранятся в двух местах: в таблице v8users и в двоичных данных таблицы Params. Выясним причину возможного рассогласования.
Иногда возникает ситуация, когда уникальные идентификаторы (UUID) пользователя в таблице v8users перестают соответствовать записям в файле параметров пользователей. Это может произойти из-за сбоя при записи в момент аварийного завершения сеанса администратора. Проанализируем состояние базы через «Тестирование и исправление» в Конфигураторе:
Если вы используете MS SQL Server, можно выполнить проверку целостности таблиц напрямую. Посмотрим на пример команды для проверки индексов:
DBCC CHECKTABLE ('v8users');
GO
DBCC CHECKTABLE ('Params');
GO
Если подозрение падает на то, что пароль кто-то или что-то меняет извне (скрипты, расширения или «скрытый» админ), нам поможет настройка аудита на уровне СУБД. Это позволит точно узнать, в какой момент и каким процессом была модифицирована таблица с пользователями.
Разберем алгоритм включения аудита в MS SQL Server:
UPDATE для таблицы v8users.После этого, как только у очередного пользователя «сбросится» пароль, мы сможем открыть журнал аудита и увидеть Application Name (имя приложения) и Login Name, которые инициировали изменения. Если в поле программы будет значиться фоновое задание 1С, значит, причину нужно искать в коде конфигурации или расширений.
Рассмотрим ситуацию, упомянутую в обсуждении: использование инструментов типа Infostart Toolkit (поможет инструментарий разработчика для анализа структуры системы 1С) или механизмов Запустить под пользователем. Эти инструменты часто используют программное создание временных параметров аутентификации. Если в процессе такой «подмены» происходит программная ошибка или аварийный разрыв соединения, платформа может не успеть вернуть исходный хэш пароля в таблицу.
Также проанализируем наличие в базе механизмов синхронизации с Active Directory или другими системами. Даже если вы не используете Windows-аутентификацию напрямую, в конфигурациях на базе БСП (Библиотека стандартных подсистем) могут работать регламентные задания по синхронизации данных сотрудников. Если в коде такого задания допущена ошибка (например, объект ПользовательИнформационнойБазы записывается без сохранения пароля), то хэш пароля будет затираться при каждом запуске задания.
Для диагностики этого случая изучим Журнал регистрации. Отфильтруем события по метаданным «Пользователи», выделим проблемного юзера и посмотрим, какие события «Изменение» происходили ночью или в периоды, когда администратор точно не вносил правки.
В некоторых версиях платформы (особенно в ветках 8.3.18.х и 8.3.20.х) наблюдались внутренние ошибки при работе с обновленными алгоритмами хеширования паролей. Выясним, как это работает: при первом входе пользователя в новой версии платформы 1С пытается перекодировать старый хэш в новый формат. Если этот процесс прерывается или база имеет расширения, модифицирующие модуль сеанса, процесс может завершиться некорректно.
Рекомендация: Если вы столкнулись с массовым характером проблемы после обновления, попробуйте обновить платформу до самого последнего стабильного релиза внутри вашей ветки. Как показывает практика, в релизах 8.3.22+ большинство проблем с «отвалом» паролей в системных таблицах было исправлено.
Подводя итог, если у вас «слетают» пароли, придерживайтесь следующего плана:
Журнал регистрации на предмет изменений пользователя фоновыми заданиями.v8users, чтобы поймать «виновника» внесения изменений на горячем.В самых тяжелых случаях помогает полное удаление пользователя из информационной базы (с предварительным сохранением его настроек через копирование UUID или использование специальных обработок) и его повторное создание вручную — для этого подойдёт универсальный инструмент для администрирования и анализа объектов 1С.