1С не принимает логин: вход в базу, веб-сервисы, HTTP и вход через Windows
Содержание
Сообщение Идентификация пользователя не выполнена означает одно: платформа 1С получила имя и пароль (или учётную запись Windows), но не нашла среди пользователей информационной базы того, кому они подходят. Сначала проверьте список пользователей в Конфигураторе: Администрирование → Пользователи. Чаще всего причина находится там же: опечатка в имени, сменённый пароль, снятый флаг аутентификации или пользователя в этой базе просто нет.
Если ошибка приходит не при ручном входе, а из обмена, веб-сервиса, HTTP-запроса или внешнего соединения, логика та же. Неверные учётные данные лежат в строке подключения, в коде или в настройках публикации на веб-сервере. Ниже разобраны оба случая: человек у экрана и программа, которая стучится в базу.
Как 1С проверяет пользователя и откуда берётся ошибка идентификации
У каждой информационной базы свой список пользователей. Он хранится внутри самой базы: в файловом варианте — в файле 1Cv8.1CD, в клиент-серверном — в базе данных на SQL-сервере. Пользователь из базы «Бухгалтерия» ничего не знает о пользователях базы «ЗУП», даже если они на одном сервере.
Платформа умеет три способа аутентификации:
- 🔑 Аутентификация 1С:Предприятия — имя и пароль, заданные в самой базе.
- 🪟 Аутентификация операционной системы — вход под учётной записью Windows, без ввода пароля.
- 🧩 OpenID и внешние провайдеры — встречаются реже, в основном при работе через веб-сервер.
Ошибка идентификации возникает, когда ни один включённый способ не дал результата. Типовые причины:
- ✏️ имя набрано не так, как в списке: лишний пробел, буква «е» вместо «ё», латинская «с» вместо кириллической;
- 🔒 пароль сменили, а в ярлыке, обмене или скрипте остался старый;
- 🚫 у пользователя сняты все флаги аутентификации — так программа «запрещает вход»;
- 📦 базу загрузили из
.dtдругой организации, и вашего пользователя там нет; - 🌐 учётная запись Windows или домен изменились, а в карточке пользователя записан старый
\\ДОМЕН\имя.
Если список пользователей в базе пуст, 1С пускает любого без запроса пароля. Ошибка идентификации появляется только тогда, когда хотя бы один пользователь создан.
Не путайте эту ошибку с запросом пароля администратора кластера. В клиент-серверном варианте сервер 1С иногда спрашивает учётные данные администратора кластера или администратора базы на сервере — это отдельные списки, не связанные с пользователями информационной базы.
Проверяем учётную запись: Конфигуратор и карточка пользователя
Начинайте с базы, а не с сети. Порядок такой.
- Запустите Конфигуратор под пользователем с полными правами.
- Откройте
Администрирование → Пользователи. - Найдите нужного пользователя и откройте карточку. На вкладке «Основные» проверьте:
- точное имя (скопируйте его в буфер, а не перепечатывайте);
- флаг «Аутентификация 1С:Предприятия» и заданный пароль;
- флаг «Аутентификация операционной системы» и поле с учётной записью Windows;
- флаг «Показывать в списке выбора».
- При необходимости задайте новый пароль и сохраните карточку.
В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) удобнее работать в пользовательском режиме. Путь: Администрирование → Настройки пользователей и прав → Пользователи. В карточке есть флаг «Вход в программу разрешен». Если его снять, программа сбрасывает все способы аутентификации у пользователя информационной базы — и при входе человек увидит именно ошибку идентификации.
В тех же карточках можно ограничить срок действия входа датой. Когда дата прошла, пользователь перестаёт входить, хотя в остальном карточка выглядит нормально. Проверьте эту настройку, если сотрудник «вчера входил, а сегодня нет».
Не создавайте второго пользователя с тем же именем «для проверки». У него будет другой внутренний идентификатор, и ссылки на прежнего пользователя (автор документов, настройки, права) к нему не перейдут.
Если входите с ярлыка или скриптом, проверьте ключи командной строки. Пример запуска с явными учётными данными:
"C:\Program Files\1cv8\common\1cestart.exe" ENTERPRISE /S "srv1c\buh" /N "Иванова" /P "пароль" /WA-
Ключ /WA- отключает попытку входа через Windows, /WA+ — наоборот, требует её. Если в ярлыке стоит /WA+, а флаг аутентификации ОС у пользователя снят, получите ту же ошибку при правильном пароле.
Ошибка идентификации пользователя в веб-сервисах и HTTP-сервисах
Это вторая по частоте ситуация. Внешняя система, сайт или другая база обращаются к опубликованной базе и получают в ответ 401 Unauthorized. Код 1С на клиентской стороне показывает это как ошибку идентификации или аутентификации.
Сторона базы, которую вызывают
Веб-сервисы и HTTP-сервисы работают через веб-сервер (IIS или Apache) и публикацию из Конфигуратора: Администрирование → Публикация на веб-сервере. Каждый запрос выполняется от имени пользователя этой базы. Проверьте:
- Есть ли в базе отдельный пользователь для интеграции. Не используйте учётку живого сотрудника: он сменит пароль — обмен встанет.
- Есть ли у этого пользователя роль с правом на нужный веб-сервис или HTTP-сервис и на объекты, которые он читает.
- Не вписаны ли учётные данные прямо в строку подключения
default.vrd.
Последний пункт часто забывают. В файле публикации строка ib= может содержать имя и пароль:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/buh"
ib="Srvr="srv1c";Ref="buh";Usr="exchange";Pwd="123";">
Если там записан пользователь со старым паролем, ошибку получат все клиенты публикации — независимо от того, что они передают.
Сторона, которая вызывает
Для HTTP-сервиса учётные данные передают в конструкторе соединения:
ЗащищенноеСоединение = Новый ЗащищенноеСоединениеOpenSSL();
Соединение = Новый HTTPСоединение("srv.example.ru", 443, "exchange", "Пароль", , 30, ЗащищенноеСоединение);
Запрос = Новый HTTPЗапрос("/buh/hs/api/orders");
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 401 Тогда
Сообщить("Сервер отклонил имя или пароль");
КонецЕсли;
Для веб-сервиса имя и пароль нужны дважды: при чтении WSDL и при вызове операций.
Определения = Новый WSОпределения("https://srv.example.ru/buh/ws/orders.1cws?wsdl", "exchange", "Пароль");
Прокси = Новый WSПрокси(Определения, "http://www.example.ru/orders", "Orders", "OrdersSoap");
Прокси.Пользователь = "exchange";
Прокси.Пароль = "Пароль";
Если WSDL читается, а вызов падает, почти всегда забыли заполнить Пользователь и Пароль у прокси.
Для интеграционного пользователя берите имя латиницей: exchange, site_api. Сторонние клиенты (PHP, Python, Postman) кодируют кириллическое имя в заголовке Basic-авторизации по-разному, и 1С его не узнаёт. Латиница снимает вопрос полностью.
HTTPS, сертификаты и прокси между клиентом и 1С
Ошибки сертификата и ошибка идентификации — разные стадии. Сначала устанавливается защищённое соединение, только потом сервер проверяет логин. Если вы видите именно Идентификация пользователя не выполнена, TLS-рукопожатие уже прошло: сертификат принят, проблема в учётных данных.
Это полезно для диагностики, но на HTTPS есть свои ловушки:
- 🔁 перенаправление с http на https. Многие HTTP-клиенты при переходе на другой адрес не повторяют заголовок авторизации. Указывайте в настройках сразу итоговый
https://-адрес; - 🛡️ корпоративный прокси или межсетевой экран. Некоторые из них вскрывают HTTPS и вырезают заголовок
Authorization. Проверьте запрос в обход прокси или с другого компьютера; - 📜 клиентский сертификат. Если веб-сервер настроен требовать сертификат клиента, его передают в
ЗащищенноеСоединениеOpenSSLпервым параметром. Без него IIS вернёт отказ ещё до 1С; - 🔐 двойная проверка на веб-сервере. Если в IIS для каталога публикации включена проверка подлинности Windows или обычная проверка, сервер требует учётку Windows. Логин 1С на этом этапе не подходит.
Последний пункт — частая причина, когда «всё правильно, а не пускает». Для публикации с аутентификацией средствами 1С на уровне IIS обычно оставляют анонимный доступ, а проверку отдают платформе.
Если же TLS не устанавливается, сообщение будет другим — про SSL, сертификат или защищённое соединение. Такую ошибку решают сертификатами удостоверяющих центров, а не паролями.
Вход через Windows и единый вход (SSO)
При аутентификации ОС 1С сверяет учётную запись, под которой вошли в Windows, с полем в карточке пользователя. Формат поля — \\ДОМЕН\имя, например \\CORP\ivanova. Нужны оба условия: флаг «Аутентификация операционной системы» включён, и запись совпадает буква в букву.
Что ломает вход через Windows:
- Переименование или переезд в другой домен. Поле в карточке осталось старым — исправьте его, выбрав пользователя кнопкой выбора рядом с полем.
- Локальная учётка вместо доменной. Сотрудник вошёл в Windows под локальным пользователем, а в 1С прописан доменный.
- Клиент-серверный вариант без Kerberos. Для сквозной проверки сервер 1С должен работать под доменной учётной записью службы, у которой зарегистрирован SPN. Регистрирует его администратор домена командой
setspn. - Терминальный сервер или RDP с другим пользователем. 1С видит того, кто вошёл в сеанс, а не того, кто сидит за компьютером.
Для веб-клиента и тонкого клиента через веб-сервер единый вход работает поверх браузера:
- в IIS для каталога публикации включается проверка подлинности Windows;
- адрес сервера 1С добавляется в зону «Местная интрасеть» в свойствах браузера (Edge, Chrome на Windows берут её из системных настроек);
- в Firefox адрес добавляют в параметр
network.negotiate-auth.trusted-urisна страницеabout:config.
Если браузер не считает сайт доверенным, он не передаёт билет Kerberos. Сервер не видит пользователя, и 1С выдаёт ошибку идентификации или показывает окно ввода пароля.
Не включайте аутентификацию ОС для всех пользователей разом в рабочей базе. Сначала настройте одного, проверьте вход с его компьютера и через веб-клиент, затем переходите к остальным. Пароль 1С при этом не удаляйте — он останется запасным способом входа.
Администрирование → Пользователи, задайте новый пароль, уберите лишние пробелы. Проверьте раскладку и Caps Lock./N и /P или /WA+. Откройте свойства базы в окне запуска и проверьте дополнительные параметры.default.vrd. Сравните с тем, что передаёт клиент.Пользователь и Пароль у объекта WSПрокси.\\ДОМЕН\имя в карточке пользователя.Журнал регистрации и логи: где увидеть, кто и как пытался войти
Когда причина не видна сразу, смотрите журнал регистрации. Он фиксирует и удачные, и неудачные попытки входа.
- В Конфигураторе:
Администрирование → Журнал регистрации. - В конфигурациях на БСП:
Администрирование → Обслуживание, группа отчётов администратора, «Журнал регистрации».
Установите отбор по событиям «Сеанс. Аутентификация» и «Сеанс. Ошибка аутентификации». По каждой записи видно время, компьютер и имя, под которым пытались войти. Так быстро находится скрипт обмена, который каждые пять минут стучится со старым паролем.
Что можно понять по журналу:
| Что видите | Что это значит |
|---|---|
| Ошибки аутентификации с одного компьютера по расписанию | Регламентный обмен или скрипт со старыми данными |
| Имя пользователя в записи отличается от ожидаемого | Опечатка или другая кодировка имени у клиента |
| Записей об ошибке нет вовсе | Запрос не дошёл до 1С — смотрите веб-сервер и прокси |
| Ошибки от учётки Windows, которой нет в базе | Вход через ОС с чужого или нового компьютера |
Если в журнале пусто, переходите к логам веб-сервера. В IIS логи по умолчанию лежат в C:\inetpub\logs\LogFiles, у Apache — в access-логе виртуального хоста. Ищите строки с кодом 401. Если 401 стоит, а в журнале 1С записи нет, отказ выдал сам веб-сервер — значит, у него включена собственная проверка подлинности.
Для глубокой диагностики на сервере 1С включают технологический журнал через файл logcfg.xml. Это инструмент администратора: журнал быстро растёт, поэтому включайте его на короткое время и с отбором по нужным событиям.
Обмены, COM-соединение, OData и другие интеграции
Внешние сценарии отличаются только местом, где хранится пароль.
Синхронизация данных между базами (БСП). В настройке синхронизации через интернет указаны имя и пароль пользователя базы-корреспондента. Сменили пароль там — обновите его в настройке синхронизации в своей базе. У пользователя в базе-корреспонденте должны быть права на синхронизацию данных, иначе после входа будет уже другая ошибка — о нехватке прав.
COM-соединение. Строка подключения содержит Usr и Pwd:
Коннектор = Новый COMОбъект("V83.COMConnector");
Соединение = Коннектор.Connect("Srvr=""srv1c"";Ref=""buh"";Usr=""exchange"";Pwd=""Пароль"";");
Строка в кавычках, кавычки внутри удваиваются. Ошибка в экранировании превращает пароль в другой набор символов, и 1С честно сообщает, что пользователя с таким паролем нет.
OData. Стандартный интерфейс OData работает через ту же публикацию базы на веб-сервере и проверяет пользователя так же, через Basic-авторизацию. Пользователю нужны права на объекты, которые читает внешняя система.
Регламентные задания и внешние планировщики. Задание в Планировщике Windows, которое запускает 1С с ключами /N и /P, — частый «невидимый» источник ошибок. Найдите его по времени ошибок в журнале регистрации.
Порядок действий для любой интеграции один: