Почему 1С 8.3 не пускает в базу и как вернуть вход пользователю

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

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

Как 1С проверяет пользователя и где ломается идентификация

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

Главная особенность: пока в базе нет ни одного пользователя, 1С пускает всех без вопросов. Как только создан хотя бы один, каждый вход проходит проверку. Поэтому ошибка нередко появляется сразу после того, как кто-то «просто добавил пользователя для нового сотрудника» в базе, где раньше списка не было.

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

• 🔑 пароль сменили, а в ярлыке или в списке баз записан старый;
• 👤 пользователя удалили или сняли у него разрешение на вход;
• 🖥 учётная запись Windows не совпадает с той, что указана в карточке пользователя;
• 🌐 на сервере 1С не проходит проверка домена (Kerberos или NTLM);
• 🔗 внешняя программа или обмен подключается со старыми реквизитами;
• 📁 в файловой базе повреждена служебная таблица пользователей.

Журнал регистрации: кто, когда и как пытался войти

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

Как открыть журнал, если у вас есть рабочий вход с правами администратора:

1. В Бухгалтерии 3.0 и ЗУП 3.1: Администрирование → Обслуживание → Журнал регистрации.
2. В Конфигураторе: Администрирование → Журнал регистрации.
3. Нажмите отбор и оставьте только событие ошибки аутентификации, период — последние сутки.

Что смотреть в найденных записях:

• Компьютер. Если попытки идут с сервера или с машины, где никто не работает , — это обмен, регламентное задание или внешняя программа со старым паролем.
• Приложение. «Тонкий клиент» означает человека, «Внешнее соединение» или «COM-соединение» — интеграцию.
• Комментарий. Здесь платформа часто пишет имя, под которым пытались войти. Видно опечатку или домен, который не совпадает с карточкой.
• Частота. Ошибка каждые 5–10 минут почти всегда означает автоматику, а не человека.

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

Проверка пользователя, пароля и параметров запуска

Это самый частый случай. Начните с него, даже если подозреваете сервер.

Карточка пользователя в базе

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

В Бухгалтерии 3.0, ЗУП 3.1 и других решениях на БСП удобнее работать через Администрирование → Настройки пользователей и прав → Пользователи. В карточке есть флажок «Вход в программу разрешён». Снятый флажок даёт тот же отказ во входе, хотя пользователь в списке есть.

Ограничения входа, о которых забывают

В БСП-конфигурациях администратор может включить запрет входа для тех, кто не заходил дольше заданного числа дней, и срок действия пароля. Сотрудник вернулся из отпуска — и не может войти. Ищите эти параметры в разделе Администрирование → Настройки пользователей и прав, в настройках входа.

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

Ярлык и список баз

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

• свойства ярлыка на рабочем столе — поле «Объект»;
• окно выбора баз: выделите базу, нажмите «Изменить» и пролистайте до поля «Дополнительные параметры запуска».

Если там записано что-то вроде этого — пароль устарел вместе со сменой в базе:

"C:\Program Files\1cv8\8.3.24.1586\bin\1cv8.exe" ENTERPRISE /F"D:\Bases\Buh" /N"Иванова" /P"старый_пароль"

Уберите /P и /N или впишите актуальные значения. Хранить пароль в ярлыке вообще плохая идея: файл списка баз ibases.v8i лежит в профиле пользователя открытым текстом.

Ещё два ключа, которые влияют на результат:

• /WA- запрещает вход через Windows. Пользователю с одной лишь аутентификацией ОС после этого ключа войти нечем.
• /WA+ требует вход через Windows, даже если в окне ввели имя и пароль.

Вход через Windows: когда сменились домен или имя

Аутентификация операционной системы — удобная вещь, пока ничего не меняется. В карточке пользователя 1С хранится строка вида \\BUH\ivanova, где BUH — домен (или имя компьютера для локальной учётной записи), ivanova — имя входа.

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

1. Компьютер перевели из рабочей группы в домен или из одного домена в другой. Было \\PC-BUH-03\ivanova, стало \\CORP\ivanova.
2. Пользователь вошёл в Windows под другой учётной записью, например под общей «Бухгалтерия».
3. Сотрудника переименовали в домене после смены фамилии.
4. Базу открыли через удалённый рабочий стол под учётной записью сервера терминалов, а не домена.

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

Сервер 1С и кластер: почему не проходит проверка домена

В клиент-серверном варианте вход через Windows проверяет не компьютер пользователя, а сервер 1С. Клиент передаёт билет Kerberos или данные NTLM, а рабочий процесс сервера должен их проверить.

Что ломает эту проверку:

• Служба сервера работает под локальной учётной записью. По умолчанию служба агента запускается под USR1CV8. Для Kerberos в домене служба должна работать под доменной учётной записью, а для неё зарегистрировано имя службы (SPN).
• Время рассинхронизировано. Kerberos отказывает, если часы клиента, сервера и контроллера домена расходятся больше чем на 5 минут (значение по умолчанию в политике домена). После смены батарейки BIOS или восстановления виртуалки из снимка это частая причина.
• Сервер 1С на Linux. Для входа через Windows нужен keytab-файл для учётной записи службы и запись SPN в домене. Без них вход по паролю 1С работает, а через Windows — нет.
• Обновили платформу на сервере. Новый каталог версии создаётся заново, и настройки вроде пути к keytab-файлу нужно перенести.

Как отличить серверную причину от клиентской:

1. Попросите пользователя войти под логином и паролем 1С. Получилось — проблема именно во входе через Windows.
2. Ошибка у всех пользователей сразу — смотрите сервер и домен.
3. Ошибка у одного — смотрите его учётную запись и компьютер.

Проверить список рабочих серверов и сеансов можно утилитой rac при запущенном сервере администрирования ras:

rac cluster list
rac session list --cluster=<ID_кластера>

Других подкоманд для этой задачи держать в голове не нужно: при сомнениях смотрите rac help.

Сеть и брандмауэр: что относится к ошибке, а что нет

Сетевые проблемы обычно выглядят иначе: сообщениями о том, что сервер не найден или соединение разорвано. Но для входа через Windows сеть важна по-своему.

Клиент-серверное взаимодействие 1С устроено так: клиент обращается к агенту сервера на порт 1540, затем к менеджеру кластера на порт 1541 и к рабочим процессам в диапазоне портов, который задают в свойствах рабочего сервера (по умолчанию 1560–1591). Если закрыт хотя бы один из этих портов, пользователь получит ошибку соединения, а не идентификации.

Ошибку именно идентификации даёт сеть, когда:

• сервер 1С не может достучаться до контроллера домена (Kerberos использует порт 88), и вход через Windows не проверяется;
• клиент подключается к серверу по IP-адресу, а не по имени. Kerberos привязан к имени сервера, и по IP проверка может не пройти;
• у сервера несколько сетевых имён, а SPN зарегистрирован только на одно.

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

Лицензии и ключи HASP: не та ошибка

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

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

Файловая база: свои причины и свои инструменты

В файловом варианте нет сервера и Kerberos, но появляются свои поводы для отказа.

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

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

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

Что делать в этом случае:

1. Закройте все сеансы и сделайте копию каталога базы целиком.
2. Запустите утилиту chdbfl.exe из каталога bin установленной платформы.
3. Укажите путь к файлу 1Cv8.1CD, отметьте «Исправлять обнаруженные ошибки» и запустите проверку.
4. Если утилита не помогла, восстановите базу из последней резервной копии.

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

Внешние соединения, обмены и веб-публикация

Ошибка идентификации пользователя часто приходит не от человека, а от программы. Признак — в журнале регистрации приложение «Внешнее соединение», «COM-соединение» или веб-сервис.

Где искать старые реквизиты:

• Обмен между базами. В настройках синхронизации данных указан пользователь второй базы. Смените пароль там же.
• COM-соединение из внешней программы. Строка подключения содержит имя и пароль:

Srvr="server1c.corp.local";Ref="buh";Usr="obmen";Pwd="пароль"

• Веб-публикация. В файле default.vrd строка подключения к базе тоже может содержать Usr и Pwd. Для входа через Windows на IIS должна быть включена проверка подлинности Windows.
• Регламентные задания. В серверной базе задание выполняется от имени пользователя, указанного в его настройках. Удалили пользователя — задание падает с той же ошибкой.

💡 Для обменов и интеграций заводите отдельного служебного пользователя с паролем без срока действия и минимальными правами. Тогда смена пароля бухгалтера не обрушит обмен.

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