Пользователь ИБ не идентифицирован: 12 из 40 не вошли в 1С в день запуска

«Пользователь информационной базы не идентифицирован» — это сообщение 1С показывает, когда база настроена на аутентификацию по учётной записи Windows, а текущий логин на компьютере или терминальном сервере не совпадает ни с одной записью в списке пользователей ИБ. Чаще всего причина — перенос базы на новый сервер или неполный перенос списка пользователей при миграции. Правится сверкой списка и способа входа, обычно за 10-20 минут на пользователя.

8:58 утра: половина бухгалтерии не может открыть новую базу

Понедельник, дистрибьютор стройматериалов на юго-востоке Москвы, 40 пользователей, склад плюс два офиса. В пятницу вечером интегратор завершил перенос данных с 1С:Управление торговлей 10.3 на 1С:ERP — три месяца проекта, тестовый контур принят, регламент запуска подписан, резервная копия снята в полночь. В 8:58 в понедельник бухгалтерия садится за терминальный сервер, чтобы закрыть остатки за прошлую неделю, и вместо рабочего стола 1С видит окно с текстом: «Пользователь информационной базы не идентифицирован». Не у всех — у 12 из 40. Кассир и логист вошли без проблем, главный бухгалтер и два её заместителя — нет. Через десять минут звонок эскалируется на интегратора: закрытие месяца стоит, и никто не понимает, почему одни коллеги вошли, а соседи по кабинету — нет.

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

что означает ошибка «пользователь информационной базы не идентифицирован»

Текст сообщения формальный, но смысл узкий: 1С не может сопоставить того, кто сейчас сидит за компьютером, ни с одной записью в списке пользователей информационной базы. Это происходит, когда для входа выбран способ аутентификации операционной системы — 1С доверяет учётной записи Windows и ищет в списке пользователей ИБ запись с точно таким же именем домена и логина. Совпадения нет — доступа нет, независимо от того, что у сотрудника есть роль, права и рабочее место в базе.

В отличие от ошибки неверного пароля, здесь дело не в правах и не в лицензии: запись пользователя в базе может существовать, но 1С её не находит, потому что сверяет не имя человека, а строку вида ДОМЕН\логин, которую операционная система передала в момент запуска. Поэтому сообщение об ошибке появляется ещё до окна ввода логина и пароля — 1С даже не успевает спросить, кто перед ней, она уже не узнала запрос от ОС.

почему совпадение по логину windows ломается при переносе базы

У всех 12 сотрудников, которые не смогли войти, было общее: они работали не с локального компьютера, а через терминальный сервер. Новый сервер под 1С:ERP подняли на отдельной машине, а старый пул терминальных сессий 1С:УТ остался на прежней. Свежий сервер выдавал новым сессиям те же логины, но домен на нём был указан иначе — короткое имя вместо полного, доставшееся от шаблона установки. Для 1С это два разных пользователя, хотя человек за клавиатурой один и тот же.

Похожая картина часто складывается у растущих компаний: открыли второе юрлицо, перевели часть сотрудников на новый филиал, добавили удалённых менеджеров на ноутбуках вне офисного домена — и каждое такое изменение инфраструктуры тихо создаёт новую строку рассинхрона между базой и Active Directory, которая всплывает не сразу, а при следующем перезапуске терминального сервера.

терминальный сервер получает новый пул сессий

Когда терминальный сервер меняют вместе с базой, доменное имя, под которым система авторизует сессию, может отличаться от того, что было в старом пуле, даже если логин человека не менялся ни разу. Проверить это на глаз нельзя — нужно сравнить строку авторизации ОС и запись в списке пользователей ИБ буква в букву, а не полагаться на то, что «логин тот же».

список пользователей копируют вместе с базой, а домен — нет

При переносе с 1С:УТ на 1С:ERP список пользователей обычно переносят вместе с базой как есть: имена, роли, привязка к физлицам. Привязка «пользователь ИБ = учётная запись ОС» переносится буквально, со старым именем домена. Если на новом сервере домен назвали иначе или завели отдельный OU для терминальных сессий, привязка рвётся у всех, кто входит через RDP, и не рвётся у тех, кто сидит за локальным ПК в старом домене — отсюда разброс «у одних работает, у других нет» в одном и том же отделе.

смена политики именования учётных записей

Реже, но тоже встречается: ИТ-служба клиента в рамках того же проекта укорачивает или переименовывает учётные записи под новый стандарт, например убирают отчество из логина. Тогда ошибка проявляется не в день запуска, а через одну-две недели, когда доходят руки до переименования конкретного отдела, и её путают с новым сбоем, хотя причина та же самая.

три способа идентификации пользователя в 1С — и где каждый подводит

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

На практике для терминальных серверов с частой пересадкой сотрудников между сессиями надёжнее стандартная аутентификация 1С или комбинация обоих способов сразу: ОС — для тех, кто работает с закреплённого места, пароль 1С — как запасной вход, который не сломается при следующей смене сервера или домена. Комбинированная схема стоит на 10-15 минут дольше в настройке на каждого пользователя, но снимает саму возможность повторения инцидента при следующем переезде инфраструктуры.

как восстановили доступ за два часа и что стоила бы задержка

Интегратор поднял протокол авторизации на новом терминальном сервере и сверил его со списком пользователей ИБ построчно — расхождение в имени домена нашлось за 20 минут. Дальше два пути: переименовать записи пользователей в базе под новый домен или добавить каждому из 12 сотрудников резервный вход по паролю 1С, не трогая привязку к ОС. Выбрали второй — он не требует переприсвоения ролей и не рискует задеть тех, у кого вход уже работал. К 10:40 все 40 пользователей были в базе, закрытие остатков сдвинулось на полтора часа, отгрузки со склада ушли по графику дня, не по графику недели.

Если бы расхождение искали не по протоколу, а перебором — кому переустановить профиль, кому сбросить пароль Windows, — на выяснение причины ушло бы полдня, а бухгалтерия сдавала бы остатки во вторник вместо понедельника. Для оптовика с ежедневной отгрузкой это конкретные заявки, которые уезжают на день позже, а не абстрактный «риск простоя», и разговор с клиентом, который переносит заказ к конкуренту.

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

что теперь входит в чек-лист миграции пользователей при внедрении

После этого случая в регламент запуска на проектах интегратора добавили отдельный шаг: до перевода боевой базы на новый сервер список пользователей ИБ сверяют со строкой авторизации ОС для каждой терминальной сессии, а не только с логином человека. Для баз, которые уходят на 1С:ERP или 1С:Управление торговлей с прежнего сервера, это делают ещё на этапе тестового контура — там расхождение видно на пяти тестовых пользователях, а не на всём отделе в день запуска.

Если после переноса нужна нестандартная схема входа — например, часть сотрудников подключается через VPN с другим доменом, а часть локально, — такую логику авторизации настраивают отдельно как доработку 1С, а не правят вручную для каждого нового человека. А когда проблема всплывает не при первом внедрении, а после планового обновления 1С или переезда на новую версию платформы, тот же порядок сверки применяют перед обновлением, а не после звонков от бухгалтерии.

как проверить это самостоятельно за пять минут, не дожидаясь интегратора

Открыть список пользователей информационной базы в конфигураторе, найти нужную запись и посмотреть поле аутентификации операционной системы — там указана строка домен\логин. Сравнить её с тем, что реально показывает командная строка на терминальном сервере для этой сессии. Если строки не совпадают хотя бы одним символом, это и есть причина, а не повреждённая база или лицензия.

Общий принцип для любого проекта внедрения 1С: список пользователей — не техническая мелочь, которую переносят по умолчанию, а отдельный пункт регламента запуска с отдельной проверкой на тестовом контуре, потому что цена ошибки здесь измеряется не в строчках лога, а в часах простоя целого отдела.

❓ Частые вопросы

Почему ошибка появляется не у всех сотрудников сразу, а выборочно?

Она зависит от того, через какой сервер или домен зашёл конкретный человек. Если часть работает через новый терминальный сервер с изменённым именем домена, а часть — с локальных ПК в старом домене, у первых логин перестаёт совпадать с записью в базе, а у вторых всё работает как раньше.

Можно ли исправить ошибку без переустановки 1С или потери настроек пользователя?

Да. Обычно достаточно поправить привязку к учётной записи ОС в списке пользователей ИБ или добавить резервный вход по паролю 1С — роли, права и настройки рабочего места при этом не трогают.

Как узнать точную причину, а не гадать между паролем, лицензией и правами?

Открыть журнал регистрации 1С и посмотреть код и время конкретной попытки входа, затем сравнить строку домен\логин из настроек пользователя ИБ с тем, что реально передаёт терминальный сервер. Расхождение видно сразу.

Стоит ли переходить со входа по Windows на пароль 1С, чтобы это не повторилось?

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

Когда стоит привлекать интегратора, а не чинить самостоятельно?

Если ошибка массовая и совпала с переносом базы на новый сервер, миграцией на другую конфигурацию или сменой домена — это системная причина, а не единичный сбой, и её разумнее закрыть в рамках проекта внедрения, а не точечными правками у каждого пользователя.