Почему 1С не пускает в базу с сообщением «Идентификация пользователя не выполнена» и как вернуть вход

Сообщение Идентификация пользователя не выполнена означает одно: платформа 1С не нашла в списке пользователей информационной базы пару «имя + пароль» или пользователя Windows, с которыми вы пытаетесь войти. Сначала проверьте раскладку и Caps Lock, потом — флаги аутентификации в карточке пользователя, и только потом лезьте в кэш, кластер и SQL.

Типичная ситуация: бухгалтер вчера спокойно работал, а сегодня после смены пароля в Windows, переноса базы на новый сервер или загрузки выгрузки .dt от коллеги получает это окно. Ошибка общая для платформы 8.3, а не для конкретной конфигурации: в БП 3.0, ЗУП 3.1 и УТ 11 исправляется она одинаково.

Откуда берётся ошибка идентификации пользователя

Список пользователей хранится внутри самой базы, в служебной таблице v8users. Пароль там лежит не в открытом виде, а в виде хеша. Поэтому «подсмотреть» пароль нельзя — можно только проверить совпадение или задать новый.

Платформа поддерживает два основных способа входа. Ошибка возникает, когда не сработал ни один из включённых для пользователя.

Основные причины, которые встречаются на практике:

• 🔤 Опечатка или не та раскладка. Пароль чувствителен к регистру, имя — нет. Лишний пробел в конце имени тоже ломает вход.
• 🗂️ Подключились не к той базе. В списке баз две записи с похожими именами, а пользователь заведён только в одной.
• 📦 Загрузили .dt из другой базы. Вместе с данными приходит и чужой список пользователей со своими паролями.
• 🪟 Сломалась привязка к Windows. Учётку перенесли в другой домен, переименовали, а в карточке пользователя 1С осталось старое имя.
• 🚫 Вход запрещён. В конфигурациях на БСП администратор снял флажок «Вход в программу разрешён» — платформа при этом отключает пользователю способы аутентификации.
• 🔑 Параметры в ярлыке или строке подключения. В ярлыке прописаны /N и /P со старым паролем, или обмен и внешняя обработка подключаются по устаревшей строке Usr=...;Pwd=....
• 💾 Повреждение базы. Таблица пользователей испорчена после аварийного выключения, и платформа не может её прочитать.

Проверка входа: карточка пользователя, ярлык и параметры запуска

Начните с того, что не требует прав администратора сервера и не трогает данные.

Шаг 1. Убедитесь, что открываете нужную базу

1. В окне запуска выделите базу и нажмите Изменить.
2. Сверьте путь к каталогу (файловая база) или пару «кластер серверов + имя базы» (клиент-серверная).
3. Если записей несколько, удалите лишние, чтобы не путаться.

Шаг 2. Запустите базу с явным окном ввода пароля

Если вход идёт через Windows и падает, заставьте платформу спросить имя и пароль. Для этого в свойствах базы, в поле дополнительных параметров запуска, укажите /WA-. То же можно сделать из командной строки:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" ENTERPRISE /F "D:\Bases\Buh" /WA-

Для клиент-серверной базы вместо /F указывают /S "srv01\buh". Номер версии подставьте свой: он совпадает с именем папки в C:\Program Files\1cv8\.

Полезные ключи для диагностики входа:

Шаг 3. Проверьте карточку пользователя

Это делает администратор базы, у которого вход работает. В конфигурациях на БСП: Администрирование → Настройки пользователей и прав → Пользователи. В Конфигураторе: Администрирование → Пользователи.

В карточке проверьте:

• ✅ флажок «Вход в программу разрешён» (в режиме 1С:Предприятие);
• ✅ включённую аутентификацию 1С:Предприятия, если пользователь входит по паролю;
• ✅ имя пользователя Windows в формате \\DOMAIN\user, если вход через ОС — после переезда домена его нужно выбрать заново;
• ✅ отсутствие лишних пробелов в имени для входа.

Там же администратор задаёт новый пароль. Пользователь сменит его на свой при следующем входе.

Кэш платформы и временные файлы: когда чистка помогает

Кэш редко бывает прямой причиной ошибки идентификации. Но он мешает после переноса базы на другой сервер, смены версии платформы или после того, как в список баз «подтянулись» старые записи с другими параметрами.

Порядок действий:

1. Попробуйте самый мягкий вариант — запуск с ключом /ClearCache.
2. Если не помогло, закройте 1С и откройте папки пользовательского кэша: %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8.
3. Удалите внутри только папки с длинными именами вида GUID (набор букв и цифр через дефис). Файл списка баз ibases.v8i в %APPDATA%\1C\1CEStart не трогайте.
4. Запустите базу заново.

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

На терминальном сервере чистить нужно в профиле того пользователя Windows, у которого ошибка, а не в своём.

Консоль кластера серверов: что проверить в клиент-серверном варианте

Для клиент-серверной базы откройте Администрирование серверов 1С Предприятия на сервере или на машине администратора.

Что смотреть:

1. Есть ли база в кластере и как она называется. Раскройте кластер → Информационные базы. Имя в окне запуска должно совпадать с именем здесь до символа. Частая ошибка — база зарегистрирована как buh_2024, а пользователи подключаются к buh, которую когда-то создали пустой.
2. Сеансы. В разделе сеансов базы видно, кто и с какого компьютера уже вошёл. Если коллеги работают, а один пользователь нет — проблема в его учётке или его компьютере, а не в сервере.
3. Свойства базы. При открытии свойств консоль спрашивает имя и пароль администратора информационной базы. Если ввести неверные, получите ту же самую ошибку идентификации — это нормальное поведение, а не сбой кластера.

Не путайте с соседними сообщениями. «Администратор кластера не аутентифицирован» касается учётки администратора кластера, а не пользователя базы. Ошибки авторизации в СУБД — про логин SQL, который указан в свойствах базы в кластере.

Для тех, кто работает через консоль командной строки, список баз и сеансов выводит утилита rac:

rac cluster list
rac infobase summary list --cluster=<id кластера>
rac session list --cluster=<id кластера>

Если нужны другие подкоманды, смотрите справку rac help.

Ещё один источник фактов — журнал регистрации. У администратора в Конфигураторе: Администрирование → Журнал регистрации. Отберите события группы «Сеанс» за нужный час: неуспешные попытки аутентификации видны с именем пользователя и компьютером. Так легко отличить опечатку конкретного сотрудника от сбоя у всех.

Сброс пароля администратора, если войти не может никто

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

Перед любыми действиями в СУБД сделайте полную резервную копию базы средствами SQL и выгоните всех пользователей. Работа идёт напрямую с таблицами, отменить её кнопкой нельзя.

Порядок для MS SQL Server

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

1. Переименуйте таблицу пользователей и пометку файла в таблице параметров:

EXEC sp_rename 'v8users', 'v8users_old';
UPDATE Params SET FileName = 'users.usr_old' WHERE FileName = 'users.usr';

2. Откройте базу в Конфигураторе. Список пользователей для платформы теперь пуст, поэтому она пустит без пароля.
3. Не закрывая Конфигуратор, верните таблицу на место. Если платформа уже создала новую пустую v8users, её удаляют:

DROP TABLE IF EXISTS v8users;
EXEC sp_rename 'v8users_old', 'v8users';
UPDATE Params SET FileName = 'users.usr' WHERE FileName = 'users.usr_old';

4. В открытом Конфигураторе зайдите в Администрирование → Пользователи, откройте администратора и задайте новый пароль.
5. Закройте Конфигуратор и проверьте вход с новым паролем.

В PostgreSQL логика та же, но таблицы называются в нижнем регистре (v8users, params), а переименование выполняется через ALTER TABLE ... RENAME TO ....

Для файловой базы аналогичный приём требует правки двоичного файла 1Cv8.1CD. Делайте это только на копии файла и только если резервной копии с известным паролем нет.

Тестирование и исправление базы, когда виновато повреждение

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

Тестирование требует монопольного доступа: все пользователи должны выйти. Перед запуском сделайте копию базы.

Через Конфигуратор:

1. Администрирование → Тестирование и исправление.
2. Включите «Реиндексация таблиц информационной базы» и «Проверка логической целостности информационной базы».
3. Режим «Тестирование и исправление», затем Выполнить.

Для файловой базы без входа в Конфигуратор есть утилита chdbfl.exe в папке bin установленной платформы. Ей нужен только путь к файлу 1Cv8.1CD, имя и пароль пользователя она не спрашивает. Поставьте галку исправления ошибок и запустите проверку.

Для клиент-серверной базы сначала проверьте саму базу средствами СУБД — например, DBCC CHECKDB в MS SQL Server, — а уже затем запускайте тестирование из Конфигуратора.

Тестирование из командной строки в пакетном режиме запускается ключом /IBCheckAndRepair, но для этого нужен рабочий вход в Конфигуратор. Если войти нельзя, сначала восстановите доступ.

Права доступа, вход через Windows и сетевые подключения

Когда вход по паролю работает, а через Windows — нет, причина обычно в учётной записи ОС.

• 🪟 Имя пользователя ОС не совпадает. Откройте командную строку у сотрудника и выполните whoami. Результат вида domain\ivanova должен соответствовать полю в карточке пользователя 1С.
• 🏢 Переезд в новый домен. Старое имя в карточке остаётся, новое не подставляется само. Выберите учётку заново.
• 🖥️ Клиент-серверная база . Проверку учётки Windows выполняет сервер 1С. Если служба агента сервера работает под локальной учётной записью без доступа к домену, вход через ОС может не проходить. На время разбирательства включите пользователю пароль 1С, чтобы он мог работать.

Для подключений, где человек не вводит пароль руками, ошибка выглядит так же, но правится в другом месте:

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

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