Проблема с идентификацией пользователя информационной базы является одной из самых неприятных и трудноуловимых ошибок в последних релизах технологической платформы 1С:Предприятие (для оперативного реагирования на сбои можно использовать HTTP-сервис для перехвата штатных исключений) — есть решение для уведомлений об ошибках в Telegram. Особенно остро она проявилась в ветке 8.3.27 и экспериментальной 8.5.1. Ошибка «Пользователь ИБ не идентифицирован» прерывает работу пользователей в самый неподходящий момент, причем зачастую это происходит спонтанно. В рамках данной статьи мы подробно разберем природу этого явления, изучим зарегистрированные ошибки вендора и определим пошаговый алгоритм стабилизации системы.
Давайте разберем, почему возникает это сообщение. В современных версиях платформы (начиная с 8.3.26) механизм аутентификации претерпел значительные изменения. Система стала более требовательной к передаче токенов безопасности между рабочими процессами кластера rphost и сервисом сеансов. Проанализируем ситуацию: когда пользователь подключается к базе, кластер создает сессию и привязывает её к конкретной записи в таблице v8users. Однако из-за ошибок в коде платформы при переключении между узлами кластера или обновлении кеша сеансов связь «сессия — пользователь» разрывается. Система видит активное соединение, но не может сопоставить его ни с одним пользователем, что и приводит к ошибке идентификации.
Ситуация осложняется в многосерверных конфигурациях. Если сервис сеансов (Session Service) и сервис управления пользователями распределены по разным рабочим серверам, микрозадержки в синхронизации данных приводят к тому, что один узел считает пользователя авторизованным, а другой — уже нет. В таких случаях может помочь механизм ограничения количества сеансов для контроля нагрузки на сервис — есть готовая обработка для управления сеансами пользователей.
Для системного администратора и разработчика важно понимать, с чем именно они имеют дело. В последних релизах 1С зафиксировано несколько ключевых багов, связанных с этой проблемой. Рассмотрим их подробнее:
8.3.27.1989. Касалась общих механизмов технологической платформы.8.3.27.2074. Была связана с регрессией в механизмах безопасности.8.3.26, 8.3.27.1964 и 8.5.1.1236.Как мы видим, вендор постоянно выпускает исправления, но ошибка периодически возвращается в новых сборках. Это указывает на глубокую переработку ядра платформы в ветке 8.5.1.
Первым и самым логичным шагом является переход на версии, где данные ошибки официально помечены как исправленные. Проанализируем рекомендации:
8.3.27, рекомендуется переходить на релизы не ниже 8.3.27.2130, хотя даже в них пользователи иногда отмечают нестабильность.8.5.1, наиболее стабильным считается релиз 8.5.1.1302 и выше.8.3.25, где данные механизмы еще не были подвергнуты радикальной переработке.Если ошибка возникает преимущественно у пользователей веб-клиента или при работе через мобильные приложения, нам необходимо обратить внимание на файл default.vrd. В новых версиях платформы изменились требования к параметрам аутентификации. Выясним, как это настроить.
Проверьте наличие параметра renew="true" в секции аутентификации. Этот параметр отвечает за корректное обновление идентификационных данных при истечении времени жизни токена. Пример структуры секции аутентификации в файле публикации:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource"
base="/YourBaseName"
ib="Srvr="ServerName";Ref="BaseName";">
<authentication renew="true" />
</point>
Добавление этого параметра заставляет платформу инициировать повторную проверку личности пользователя вместо того, чтобы просто сбрасывать сессию с ошибкой «не идентифицирован».
Разберем ситуацию, когда кластер состоит из нескольких рабочих серверов. Часто проблема кроется в «рассинхроне» между узлами. Чтобы исключить этот фактор, мы можем попробовать закрепить критически важные сервисы за центральным сервером. Для удобной настройки этих параметров можно использовать альтернативную консоль администрирования кластера 1С.
Выполните следующие шаги в консоли администрирования кластера (MMC или через утилиту ras) (удобнее через обработку для онлайн-администрирования кластеров):
Таким образом, все данные об идентификации будут консолидированы в рамках одного процесса rmngr, что минимизирует вероятность потери данных о пользователе при передаче между процессами.
Проанализируем еще одну неочевидную причину. В тестовых сборках 8.3.27 выявлена повышенная чувствительность к регистру имен при использовании доменной авторизации (Active Directory). Если в 1С пользователь заведен как Ivanov, а в ОС он авторизован как ivanov, в определенные моменты (например, при обращении к серверным вызовам через BackgroundJobs) сопоставление может дать сбой.
Рекомендация: Приведите имена пользователей в списке 1С в полное соответствие с именами в Active Directory, включая регистр символов. Также стоит временно отключить OpenID-аутентификацию, если она используется, для проверки стабильности системы без этого прокси-слоя.
Если вышеуказанные методы не помогают оперативно, рассмотрим методы «ручной» очистки системы, которые часто помогают снять остроту проблемы:
snccntx, которая находится в каталоге данных кластера (обычно внутри папки reg_1541). Там хранятся временные данные сеансов, которые могут быть повреждены.v8users, если в ней возникли ошибки после некорректного обновления платформы.Подводя итог, можно сказать, что ошибка «Пользователь ИБ не идентифицирован» — это комплексная проблема, связанная с эволюцией платформы. Сочетание обновления на последние корректирующие релизы (например, 8.3.27.2130) и правильная настройка параметров публикации renew="true" в большинстве случаев позволяют победить это «зло».