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

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

Ошибка общая для платформы 8.3 и не зависит от конфигурации: она одинаково выглядит в Бухгалтерии, ЗУП, УТ и самописных базах. Ниже порядок проверок от самой частой причины к редкой, включая случай, когда пароль администратора потерян и войти не может никто.

С чего начать: что именно ввёл пользователь

Прежде чем лезть в настройки, выясните, как человек входит. От этого зависит, где искать причину.

Быстрые проверки, которые закрывают большую часть обращений:

• ⌨️ раскладка и Caps Lock — пароль чувствителен к регистру;
• 🔤 имя в базе может отличаться от ФИО: «Иванова А.» и «Иванова Анна» — разные строки;
• ␣ пробел в конце имени при ручном вводе;
• 📋 другая база в списке: у двух баз одно название, а пользователь создан только в одной;
• 🔁 недавно меняли пароль, а в ярлыке остался старый.

Проверка карточки пользователя и способов входа

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

В Конфигураторе

1. Откройте базу в режиме Конфигуратор под администратором.
2. Перейдите в Администрирование → Пользователи.
3. Найдите сотрудника и откройте свойства двойным щелчком.
4. На вкладке «Основные» проверьте флажки способов аутентификации.

Что смотреть в свойствах:

• ✅ «Аутентификация 1С:Предприятия» — вход по имени и паролю. Если флажок снят, пароль никто не примет, даже верный.
• ✅ «Показывать в списке выбора» — если снят, имени нет в выпадающем списке. Войти можно, но имя придётся набирать вручную.
• ✅ «Аутентификация операционной системы» и поле с именем пользователя Windows в формате \\ДОМЕН\имя.
• 🔑 Пароль: если сотрудник его забыл, задайте новый здесь же и попросите сменить после входа.

В режиме 1С:Предприятие

В типовых конфигурациях на базе БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) пользователей удобнее вести из самой программы: Администрирование → Настройки пользователей и прав → Пользователи.

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

1. Флажок «Вход в программу разрешен». Когда он снят, программа отключает пользователю все способы аутентификации, и при входе появляется именно наша ошибка.
2. Ограничение срока действия входа. Если администратор задал дату окончания или запрет входа после долгого простоя, программа сама снимает разрешение на вход по наступлении условия.
3. Способы входа и пароль — по ссылке настроек входа в карточке.

Роли и RLS: когда виноваты права, а когда нет

Частая ошибка диагностики — искать причину в ролях. Роли и ограничения доступа на уровне записей (RLS) проверяются уже после того, как пользователь опознан. Если идентификация не прошла, до прав дело не дошло.

Как отличить одно от другого:

Когда роли всё же влияют на вход:

• 👤 в Конфигураторе у пользователя не отмечено ни одной роли, дающей право на запуск клиента;
• 🧩 после обновления или доработки конфигурации профиль групп доступа потерял роль базовых прав;
• 🛠️ в БСП пользователь исключён из всех групп доступа — программа пускает, но почти ничего не показывает.

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

Вход через Windows и параметры запуска

Аутентификация операционной системы

Когда окно ввода пароля не появляется, а сразу выходит ошибка, 1С пытается опознать человека по учётной записи Windows. Платформа сравнивает текущего пользователя Windows с полем в свойствах пользователя базы. Не совпало — ошибка.

Типичные причины несовпадения:

• 🏢 компьютер перевели в другой домен или переименовали домен;
• 💻 пользователь вошёл в Windows под локальной учётной записью, а в базе указана доменная;
• 🔄 в базе прописан \\ДОМЕН\ivanova, а учётную запись в домене переименовали в ivanova.a;
• 🖥️ на терминальном сервере человек зашёл под общей учётной записью.

Как исправить:

1. Узнайте точное имя текущего пользователя Windows командой в командной строке:

whoami

2. В свойствах пользователя в Конфигураторе нажмите кнопку выбора рядом с полем аутентификации ОС и выберите учётную запись заново, либо впишите её в формате \\ДОМЕН\имя.
3. Если нужен вход по паролю, а не через Windows, включите «Аутентификация 1С:Предприятия» и задайте пароль.

Параметры строки запуска, которые управляют этим поведением:

В клиент-серверном варианте аутентификация ОС проходит через сервер 1С. Служба сервера работает под своей учётной записью (часто USR1CV8), и для входа через Windows по протоколу Kerberos этой учётной записи нужна корректная регистрация в домене. Если вход через Windows не работает ни у кого, а пароли работают — это задача администратора домена.

Ярлыки, bat-файлы и строка подключения

Ошибка появляется без всякого окна, если база запускается с заданными заранее именем и паролем. Где искать такие параметры:

• 📌 свойства ярлыка на рабочем столе — поле «Объект»;
• 📄 bat-файлы для ночных обменов, обновлений и выгрузок;
• ⚙️ свойства базы в списке баз — поле дополнительных параметров запуска;
• 🔗 строки внешнего соединения и COM-подключения в обработках обмена.

Пример корректного пакетного запуска Конфигуратора:

"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /F "D:\Base\Buh" /N "Администратор" /P "пароль" /DisableStartupMessages

Что проверить в такой строке:

1. Имя после /N совпадает с именем в базе символ в символ, включая пробелы. Имя с пробелом — в кавычках.
2. Пароль после /P актуален. Пустой пароль указывают как /P "" или не указывают вовсе.
3. Путь /F (файловая база) или /S "сервер\база" (клиент-серверная) ведёт к нужной базе.

Для внешнего соединения те же поля называются Usr и Pwd:

Srvr="srv1c";Ref="buh";Usr="Обмен";Pwd="пароль";

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

Кэш клиента и служебные файлы

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

• 🗂️ базу заменили — загрузили .dt или подложили другой файл по тому же пути, а клиент ведёт себя по-старому;
• 🖥️ ошибка воспроизводится на одном компьютере, а с другого тот же пользователь входит.

Как почистить:

1. Закройте все окна 1С на этом компьютере.
2. Запустите клиент с параметром очистки кэша:

"C:\Program Files\1cv8\common\1cestart.exe" /ClearCache

3. Если не помогло, удалите папки с длинными именами-идентификаторами внутри %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8.

Файл со списком баз ibases.v8i не удаляйте: в нём только перечень баз, и потеря файла добавит работы, не решив проблему.

Пароль администратора потерян: восстановление через СУБД

Худший сценарий — никто не помнит пароль единственного администратора. Конфигуратор не открывается, создать пользователя некому. Это решается только на уровне хранения данных и только для собственной базы.

Сделайте полную резервную копию базы средствами СУБД или копию файла 1Cv8.1CD до любых действий.

Пользователи информационной базы хранятся в служебной таблице v8users. Когда платформа не находит в ней ни одного пользователя, она пускает в базу без запроса пароля. На этом построен приём для клиент-серверной базы на MS SQL:

1. Остановите работу пользователей в базе: все сеансы будут прерваны, делайте это в нерабочее время.
2. В SQL Server Management Studio выполните переименование таблицы пользователей и записи в служебной таблице параметров:

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

3. Откройте Конфигуратор — он запустится без пароля.
4. Не закрывая Конфигуратор, верните имена обратно:

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

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

Команду DROP TABLE на шаге 4 выполняйте, только если платформа успела создать новую пустую таблицу v8users; если её нет, сразу переходите к переименованию.

Для файловой базы прямого SQL нет. Таблицы внутри 1Cv8.1CD правят сторонними утилитами для работы с файлом базы, только на копии и только когда других вариантов не осталось. Надёжнее найти последнюю резервную копию, где пароль известен, или обратиться к обслуживающему партнёру.

Журнал регистрации и технологический журнал

Когда причина неочевидна — ошибка у одного пользователя через раз или после ночи — посмотрите журнал.

Журнал регистрации

Откройте его в Конфигураторе через Администрирование → Журнал регистрации или в программе через Администрирование → Обслуживание → Журнал регистрации.

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

Что подсказывает журнал:

• 📈 десятки неудачных попыток подряд с одного компьютера — сохранённый неверный пароль в обмене или скрипте;
• 🕒 ошибки строго в одно время ночью — регламентное задание или bat-файл;
• 👥 ошибки у всех сразу после определённой даты — меняли домен, пароль служебного пользователя или загружали базу.

Технологический журнал

Для клиент-серверной базы, где журнала регистрации мало, включите технологический журнал файлом logcfg.xml в каталоге conf платформы на сервере. Достаточно записывать исключения:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1c_techlog" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

После диагностики удалите файл или переименуйте его: журнал быстро растёт и нагружает диск.

Веб-клиент, тонкий клиент по http и HTTP-сервисы

Через браузер ошибка выглядит так же, но причины часто лежат в публикации на веб-сервере.

Где смотреть:

1. Файл default.vrd в каталоге публикации. В строке подключения атрибута ib могут быть заданы Usr и Pwd. Если они есть и устарели, ошибку получат все, кто заходит по этой ссылке.
2. Способ аутентификации на веб-сервере. Чтобы вход через Windows работал в браузере, на IIS должна быть включена проверка подлинности Windows, а в базе у пользователя — аутентификация ОС. С анонимным доступом IIS платформа не узнает пользователя Windows.
3. Имя базы в адресе. Ссылка http://server/buh открывает ту базу, что указана в публикации, а не ту, что в списке у пользователя.

Для тонкого клиента, подключённого к базе по http-адресу, действуют те же правила: учётная запись берётся из базы, указанной в публикации.

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

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