Пользователь 1С не идентифицирован: почему не пускает в базу и как восстановить доступ

Сообщение «Пользователь ИБ не идентифицирован» значит, что платформа не смогла сопоставить входящий сеанс с пользователем информационной базы: нет подходящей записи, не сработала аутентификация ОС, не переданы /N и /P либо база пострадала при сбое. Ниже — как отличить причины, вернуть доступ и не потерять данные.

Что значит «Пользователь ИБ не идентифицирован» и чем это не «неверный пароль»

Эту ошибку мне пересылают почти каждый месяц, и всегда с одной и той же интонацией: «1С не пускает, пароль точно правильный». Я сразу уточняю, какой именно текст на экране. Если платформа ругается на имя или пароль, речь о банальном вводе. А вот «Пользователь ИБ не идентифицирован» — другое: платформа вообще не смогла определить, кто к ней пришёл. Это уже не про опечатку, а про то, как устроена аутентификация в вашей базе. Если у вас нет своего специалиста по сопровождению 1С и баз на PostgreSQL, эту диагностику лучше сделать до того, как кто-то полезет «чинить» базу руками.

Идентификация в 1С устроена так. У информационной базы есть собственный список пользователей, и вход идёт либо по имени и паролю из этого списка, либо по аутентификации операционной системы, когда платформа берёт учётную запись Windows и ищет пользователя базы, привязанного к ней. Ошибка появляется, когда ни один из путей не дал результата или когда сам список пользователей недоступен платформе. Поэтому первое, что я выясняю: где именно возникает сообщение. В режиме «1С:Предприятие», в Конфигураторе, при запуске из планировщика, при обращении к веб-сервису? От ответа зависит всё остальное.

Отдельно скажу про формулировки. На практике встречаются близкие по смыслу сообщения, и в разных версиях платформы текст может слегка отличаться. Поэтому я прошу присылать скриншот целиком, а не пересказ. И ещё одно наблюдение: если сообщение выскакивает в Конфигураторе, а обычный вход работает, или наоборот, это уже половина диагноза. В обсуждениях на профильных форумах такие случаи описаны регулярно, и общее у них одно: сбой не в пароле, а в связке «база — платформа — способ входа».

Пять причин ошибки: от самой частой к самой неприятной

Первая и самая частая причина — вход идёт не тем способом, который ждёт база. Например, у пользователя в базе включена аутентификация ОС, а ярлык запускается с ключом, который её отключает. Или наоборот: пользователь базы создан с паролем, а клиент пытается войти «под Windows». Ключ /WA+ включает аутентификацию ОС, /WA- отключает её; это распространённые ключи командной строки, но точное поведение сверяйте по документации вашей версии платформы. Нередко ярлык, оставшийся от старой настройки, годами работал и «сломался» после смены учётной записи Windows или переименования пользователя в домене.

Вторая причина — в базе не оказалось пользователя, соответствующего входящему. Так бывает после переноса базы с копии, после загрузки выгрузки .dt в новую базу и после чистки списка пользователей. Администратор удалил «лишних», в числе которых оказалась служебная учётная запись, под которой работают обмены. Третья — запуск в неинтерактивном режиме: регламентный скрипт, планировщик Windows, фоновая выгрузка. Там нет окна ввода пароля, и без /N и /P платформа не знает, кто она. Четвёртая — особенность конкретных версий платформы: в обсуждениях приводят релизы 8.3.16.1814, 8.3.17.1851 и 8.3.18.1208, где после аварийного завершения Конфигуратора вход переставал работать. Это сведения из практики сообщества, поэтому проверяйте свой релиз и описание исправлений у вендора.

Пятая причина самая неприятная: повреждение базы после сбоя. Типичный сценарий — Конфигуратор упал во время сохранения конфигурации, тестирования и исправления либо обновления конфигурации, после чего вход блокируется. В обычном режиме при этом может вылезти «нарушение прав доступа», в Конфигураторе — наше сообщение. Тут быстрых способов нет, и я не пытаюсь «оживить» базу, если есть свежая копия. Разумнее восстановиться и сравнить, что потеряно. Об устройстве прав и аудите пользователей я писал в статье про права и аудит в 1С, там же объяснил, зачем администратору держать минимум двух полноправных пользователей.

• Способ входа не совпал: ключи /WA+ и /WA-, аутентификация ОС у пользователя базы.
• Пользователя нет в списке: перенос базы, загрузка .dt, чистка учётных записей.
• Неинтерактивный запуск без /N и /P: планировщик, скрипты, выгрузки.
• Особенность релиза платформы: сверяйте номер релиза и описание исправлений.
• Повреждение после сбоя: падение Конфигуратора при сохранении, ТиС или обновлении.

Как вернуть доступ: порядок действий без риска для данных

Порядок у меня всегда один, и я его не меняю. Шаг первый — остановиться и сделать копию того, что есть. Для файловой базы это копия каталога с файлом базы при закрытых сеансах, для клиент-серверной — резервная копия средствами СУБД и, если вход в Конфигуратор возможен, выгрузка в файл .dt через меню «Администрирование — Выгрузить информационную базу». Копия делается до любых экспериментов: даже безобидная «перезапись списка пользователей» иногда оставляет базу в неожиданном состоянии. Если копию снять нельзя, потому что платформа не пускает вообще, копируйте на уровне файлов или СУБД.

Шаг второй — определить, где ломается вход. Проверьте, пускает ли база в Конфигуратор под другим администратором и открывается ли она в режиме «1С:Предприятие». Если вход под другим пользователем есть, откройте список пользователей (в Конфигураторе это «Администрирование — Пользователи») и проверьте нужную запись: имя, способ аутентификации, галочку аутентификации ОС и привязанную учётную запись Windows. Часто хватает исправить именно её. Если вы пользуетесь аутентификацией ОС, убедитесь, что в ярлыке нет ключа /WA-, который её отключает.

Шаг третий — временный обход через параметры запуска, когда нужно срочно открыть базу и список пользователей читается нормально. В поле «Дополнительные параметры запуска» в настройках информационной базы или прямо в командной строке передают имя пользователя и пароль ключами /N и /P. Пример для файловой базы из командной строки cmd (путь к 1cv8.exe зависит от установленного релиза; пути и значения с пробелами берите в кавычки):

"C:\Program Files\1cv8\<релиз>\bin\1cv8.exe" ENTERPRISE /F "C:\1C\Base" /N "Ivanov" /P "ПарольПользователя" /WA-

Ключ /WA- здесь запрещает аутентификацию средствами ОС при старте, чтобы платформа не подставляла учётную запись Windows вместо переданных имени и пароля; без ключа по умолчанию действует /WA+. Для Конфигуратора вместо ENTERPRISE пишут DESIGNER, для клиент-серверной базы вместо /F указывают /S «сервер\имя_базы». Учтите: пароль в ярлыке или в строке запуска хранится открытым текстом. Это допустимо для разового запуска и для служебного скрипта на закрытом сервере, но не как постоянная схема для сотрудников. Для регламентных задач заведите отдельного пользователя с минимальными правами и не используйте для них учётку главного администратора.

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

Ошибка появилась после сбоя Конфигуратора, ТиС или обновления: восстановление

Если Конфигуратор упал при сохранении или базу прервали в момент тестирования и исправления, я исхожу из того, что целостность базы нарушена, пока не доказано обратное. В обсуждениях сообщества описан сценарий, где после такого падения Конфигуратор отвечал «Пользователь ИБ не идентифицирован», а режим «1С:Предприятие» — нарушением прав доступа; причину связывали с ошибкой платформы в нескольких релизах 8.3.16–8.3.18. Для вашей версии я бы проверил описание исправлений и обновился на релиз, где ошибка устранена. Но сначала нужно вернуть работоспособную базу.

Рабочий путь, который я использую: создаю временную чистую базу, разворачиваю в неё последнюю выгрузку .dt или копию из бэкапа и проверяю, что вход и ключевые документы на месте. Если нужна именно рабочая база на сервере, дальше переношу данные штатным способом СУБД — восстановлением резервной копии в рабочую базу. Так пишут и те, кто сам прошёл этот путь: развернули ИБ из .dt, сделали новую копию средствами SQL и восстановили её в рабочую. Важен порядок: не поверх повреждённой базы, а рядом, с сохранением оригинала для разбора.

Чего я не делаю — и не советую делать без поддержки вендора: править служебные таблицы SQL-базы «по рецепту с форума». В сети можно встретить готовые запросы, меняющие статус в служебных таблицах. Они иногда помогают, но это вмешательство в хранилище, которое платформа не предназначена для ручных правок, и последствия на вашей версии не проверены. Если копии нет совсем, лучше передать базу специалисту, чем экспериментировать на единственном экземпляре. Про организацию копий и ротацию я подробно писал в статье про автовыгрузку и ротацию бэкапов 1С.

Регламентные задания, обмены и веб-сервисы: когда «ломается» не человек, а процесс

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

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

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

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

Разбор из практики: питомник «Королевский двор», 13 рабочих мест

Условный клиент — питомник животных «Королевский двор», 13 рабочих мест, одна клиент-серверная база 1С. В понедельник утром бухгалтер позвонила: Конфигуратор не пускает, пишет «Пользователь ИБ не идентифицирован». В пятницу вечером внешний подрядчик запускал тестирование и исправление базы, сеанс Конфигуратора оборвался, и до понедельника об этом никто не знал. Рабочий режим тоже вёл себя странно: у части сотрудников вход шёл, у остальных нет. Размер базы — около 6 ГБ, ночную резервную копию СУБД снимали в 02:00, а выгрузку .dt раз в неделю.

Первое, что мы сделали в понедельник, — остановили вход в базу и сняли копию текущего состояния, чтобы было что разбирать. Второе — проверили всё, что можно проверить снаружи: ярлыки и параметры запуска у сотрудников не менялись, аутентификация ОС в домене работала, учётные записи Windows не заблокированы. Единственный администратор базы в Конфигуратор тоже не входил. Стало ясно, что дело не в способе входа, а в самой базе. Ночные копии субботы и воскресенья сняты уже после сбоя, поэтому развернули временную базу из копии СУБД за пятницу 02:00 — последней до запуска ТиС. Проверили вход, список пользователей и ключевые документы, убедились, что данные целы. Решение приняли в пользу восстановления, а не ремонта: копия свежая, а правки служебных таблиц на единственной базе — риск без гарантий.

Итог по срокам: от звонка до рабочей базы прошло 2 часа 40 минут. Потеряна работа за пятничный день — с 02:00 до запуска ТиС: по документам это 14 вручную введённых записей, которые бухгалтер восстановила по бумагам за час. Дальше мы сделали три вещи: добавили второго администратора базы, перевели выгрузку .dt с еженедельной на ежедневную и запретили подрядчику запускать ТиС без согласования. Не буду утверждать, что это единственная верная схема, но ошибка с тех пор не повторялась. Для питомника с 13 рабочими местами этого достаточно.

Как не получать эту ошибку: минимум дисциплины

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

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

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

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