Почему 1С не пускает в базу с ошибкой идентификации и как войти

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

Почти всегда виновато одно из пяти: неверный пароль или имя в ярлыке, пользователь без нужной галочки аутентификации, учётная запись Windows не привязана к пользователю 1С, Kerberos в клиент-серверном варианте не проходит, браузер не передаёт учётные данные в веб-клиент. Ниже — как быстро понять, какой случай ваш, и что делать в каждом. Всё сказанное относится к платформе 8.3 и не зависит от конфигурации: БП, ЗУП и УТ проверяют вход одинаково.

С чего начать диагностику

Сначала ответьте себе на три вопроса. Они сразу отсекают половину вариантов.

• 🔑 Как пользователь входит? Вводит имя и пароль в окне входа или база открывается сама, без окна (это вход через Windows).
• 🖥️ Какая база? Файловая (папка с 1Cv8.1CD) или клиент-серверная (в строке подключения есть Srvr=).
• 👥 У всех или у одного? Если не пускает всех — проблема в сервере, домене или публикации. Если одного — в карточке пользователя или на его компьютере.

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

Как проверить учётную запись и права пользователя

Карточку пользователя открывает только тот, у кого есть административные права. Удобнее всего — из Конфигуратора: Администрирование → Пользователи. В типовых конфигурациях на «Такси» тот же список есть в режиме Предприятия: Администрирование → Настройки пользователей и прав → Пользователи.

В свойствах пользователя проверьте по порядку:

1. Галочка «Аутентификация 1С:Предприятия». Если её нет, вход по паролю для этого пользователя закрыт. Ввести правильный пароль не поможет — будет та же ошибка.
2. Пароль. Если сотрудник его забыл, задайте новый. Узнать старый нельзя: платформа хранит не пароль, а его хеш.
3. Галочка «Аутентификация операционной системы» и поле с учётной записью в виде \\DOMAIN\ivanov. Имя домена и логин должны совпадать с теми, под которыми человек входит в Windows.
4. Имя пользователя. Пробел в конце или буква «е» вместо «ё» — уже другой пользователь.

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

Блокировка после неудачных попыток

В новых версиях платформы 8.3 в Конфигураторе есть Администрирование → Параметры информационной базы. Там задают требования к паролю и ограничение числа неудачных попыток входа. Если ограничение включено, после нескольких ошибок пользователь блокируется на заданное время — и даже верный пароль какое-то время не принимается. Подождите или ослабьте настройку, если она мешает работе.

Если не может войти никто, включая администратора

Не пытайтесь «вылечить» базу правкой файлов. Порядок такой:

• вспомните, нет ли пользователя, у которого включён вход через Windows, — им можно войти без пароля и сбросить пароль администратору;
• восстановите базу из резервной копии, где пароль известен;
• в клиент-серверной базе обратитесь к администратору сервера и СУБД — у него есть доступ к копиям.

Вход через Windows: как он работает и почему ломается

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

Частые причины:

• 🔄 Сотрудника перевели в другой домен или сменили логин. В 1С осталось старое имя \\OLDDOMAIN\ivanov.
• 📦 Базу загрузили из .dt другой организации. Пользователи приехали с чужими доменными именами.
• 💻 Человек вошёл в Windows под локальной учёткой, а в 1С привязана доменная.
• 🖨️ Удалённый рабочий стол. Пользователь подключён к терминальному серверу под другой учётной записью, чем на своём компьютере.

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

1. Запустите 1С с параметром /WA-: он отключает вход через Windows для этого запуска, и появится обычное окно ввода имени и пароля.
2. Войдите пользователем с административными правами.
3. Откройте карточку проблемного пользователя и выберите учётную запись Windows заново через кнопку выбора рядом с полем. Ручной ввод тоже работает, но выбор из списка исключает опечатку.
4. Сохраните и попробуйте войти обычным способом.

Параметры можно прописать в ярлык или в свойства базы в окне запуска (поле дополнительных параметров запуска):

"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /WA- /N"Иванов" /P"пароль"

Противоположный параметр /WA+ принудительно включает вход через Windows. Если ярлык достался от предыдущего сотрудника, проверьте, нет ли там /WA+ или чужого /N.

Настройки кластера и домена в клиент-серверном варианте

В клиент-серверной базе вход через Windows проверяет не клиент, а сервер 1С. Клиент передаёт ему билет Kerberos, сервер его проверяет. Если проверка не удалась — та же ошибка Идентификация пользователя не выполнена, причём сразу у многих пользователей.

Что проверить администратору сервера:

SPN регистрирует администратор домена командой setspn для учётной записи, под которой запущена служба агента. Обычно это usr1cv8, а SPN имеет вид usr1cv8/имя_сервера; точный вид для вашей версии сверьте с документацией к платформе.

setspn -S usr1cv8/srv1c DOMAIN\usr1cv8
setspn -S usr1cv8/srv1c.domain.local DOMAIN\usr1cv8

Ключ -S сначала проверяет дубли и только потом добавляет запись. Дубль SPN на двух учётных записях — тоже причина отказа Kerberos.

Если сеансы не проходят только у пользователей, подключённых по IP, замените в строке подключения IP на имя сервера. При обращении по адресу Windows пытается перейти на NTLM, а он в вашем домене может быть запрещён политикой.

Веб-клиент и тонкий клиент через HTTP

Через браузер или тонкий клиент по адресу http://... база проверяет вход через веб-сервер. Вход по паролю обычно работает сразу. Вход через Windows — только если веб-сервер и браузер настроены на передачу учётных данных.

Настройка веб-сервера

На IIS для каталога публикации включите проверку подлинности Windows и выключите анонимную. На Apache для этого нужен отдельный модуль проверки подлинности, по умолчанию его нет. Если анонимный доступ включён, браузер не отправит учётные данные, и 1С увидит «никого».

Настройка браузера

Браузер отдаёт билет Kerberos только доверенным адресам:

• Edge и Chrome — адрес публикации должен быть в зоне «Местная интрасеть» или в групповой политике AuthServerAllowlist.
• Firefox — параметр network.negotiate-auth.trusted-uris в about:config.

Сертификаты и HTTPS

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

Для разового входа в веб-клиент имя и пароль можно передать в адресе:

https://srv1c.domain.local/buh/ru_RU/?N=Иванов&P=пароль

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

Очистка кэша и ярлыков на рабочем месте

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

1. Закройте все окна 1С на этом компьютере.
2. Откройте окно запуска, выделите базу и нажмите «Изменить». Проверьте строку подключения и поле дополнительных параметров запуска — нет ли там чужого /N или /WA+.
3. Запустите базу с параметром /ClearCache — он очищает кэш клиента для этой базы.
4. Если не помогло, вручную очистите кэш: папки с именами вида GUID в %APPDATA%\1C\1cv8\ и %LOCALAPPDATA%\1C\1cv8\.

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

Внешние соединения, обмены и регламентные задания

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

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

Что проверить:

• 🧾 Usr и Pwd совпадают с пользователем в базе. После смены пароля этого пользователя обмен ломается в ту же минуту.
• 🔐 У пользователя для обмена включена «Аутентификация 1С:Предприятия». Вход через Windows для внешнего соединения работает от имени учётной записи, под которой запущен скрипт или служба, а не от имени того, кто его настраивал.
• 🗓️ Служба планировщика. Если задание запускает Планировщик Windows, проверьте, под какой учётной записью оно выполняется.

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

Типичные промахи при исправлении

• ❌ Снять у пользователя оба вида аутентификации. Такой пользователь не войдёт ни одним способом.
• ❌ Привязать одну учётную запись Windows к двум пользователям 1С. Так бывает после загрузки пользователей из другой базы: человек входит не под тем именем, которое ожидает, с чужими правами. Проверьте список на совпадающие учётные записи.
• ❌ Удалить пользователя и создать заново с тем же именем. Для платформы это новый пользователь: в типовых конфигурациях придётся заново связать его с элементом справочника «Пользователи», настройками и правами.
• ❌ Чинить Kerberos переустановкой платформы. Переустановка не меняет ни SPN, ни учётную запись службы.