Проблема с идентификацией пользователя информационной базы является одной из самых неприятных и трудноуловимых ошибок в последних релизах технологической платформы 1С:Предприятие (для оперативного реагирования на сбои можно использовать HTTP-сервис для перехвата штатных исключений) — есть решение для уведомлений об ошибках в Telegram. Особенно остро она проявилась в ветке 8.3.27 и экспериментальной 8.5.1. Ошибка «Пользователь ИБ не идентифицирован» прерывает работу пользователей в самый неподходящий момент, причем зачастую это происходит спонтанно. В рамках данной статьи мы подробно разберем природу этого явления, изучим зарегистрированные ошибки вендора и определим пошаговый алгоритм стабилизации системы.
Давайте разберем, почему возникает это сообщение. В современных версиях платформы (начиная с 8.3.26) механизм аутентификации претерпел значительные изменения. Система стала более требовательной к передаче токенов безопасности между рабочими процессами кластера rphost и сервисом сеансов (подробнее о механизмах читайте в статье про Access и Refresh токены в 1С). Проанализируем ситуацию: когда пользователь подключается к базе, кластер создает сессию и привязывает её к конкретной записи в таблице 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, где данные механизмы еще не были подвергнуты радикальной переработке.Если ошибка возникает преимущественно у пользователей веб-клиента или при работе через мобильные приложения (особенно если вы использовали скрипт для автоматической установки Apache), нам необходимо обратить внимание на файл 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>
Добавление этого параметра заставляет платформу инициировать повторную проверку личности пользователя вместо того, чтобы просто сбрасывать сессию с ошибкой «не идентифицирован».
Разберем ситуацию, когда кластер состоит из нескольких рабочих серверов. Часто проблема кроется в «рассинхроне» между узлами. Чтобы исключить этот фактор, мы можем попробовать закрепить критически важные сервисы за центральным сервером.
Выполните следующие шаги в консоли администрирования кластера (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" в большинстве случаев позволяют победить это «зло».