Как настроить доменную авторизацию при подключении через веб-сервис или COM-соединение в 1С?

При интеграции информационных баз 1С разработчики часто сталкиваются с необходимостью подключаться к внешним базам или веб-сервисам с использованием сквозной доменной аутентификации (Windows Authentication). Однако при попытке программно создать WSОпределения или вызвать V83.COMConnector соединение либо завершается ошибкой «Аутентификация пользователя не выполнена», либо подключение выполняется от имени служебного пользователя сервера 1С, а не текущего пользователя операционной системы.

Проанализируем архитектурные причины такого поведения платформы 1С:Предприятие и разберем варианты решения данной задачи.

Почему не работает доменная авторизация текущего пользователя на сервере?

Рассмотрим, в каком контексте исполняется программный код. Объекты платформы WSОпределения, WSПрокси и COMConnector имеют область доступности «Сервер, толстый клиент, внешнее соединение». В режиме тонкого клиента на стороне клиентского приложения эти объекты недоступны напрямую, поэтому их создание обычно выносят в серверные процедуры (с директивой &НаСервере).

Здесь кроется ключевая особенность клиент-серверной архитектуры 1С:

1. Подмена контекста безопасности: когда тонкий клиент отправляет вызов на сервер, физический сетевой или COM-запрос инициирует рабочий процесс кластера 1С (rphost). Соответственно, запрос к внешней системе или веб-серверу идет от имени учетной записи операционной системы, под которой запущена сама служба 1C:Enterprise Server Agent (например, локальный пользователь usr1cv8 или выделенная сервисная доменная учетная запись).
2. Отсутствие автоматического делегирования (проблема Double Hop): сервер 1С не передает Kerberos-тикет интерактивного пользователя дальше по цепочке в сторонние сервисы без специальной настройки сквозного делегирования в Active Directory.
3. Поведение в толстом клиенте: если запустить базу под толстым клиентом управляемого приложения, код серверных модулей без признака «Вызов сервера» исполняется локально на рабочей станции пользователя. В этом случае обращение идет непосредственно из процесса 1cv8.exe, имеющего маркер безопасности вошедшего в Windows пользователя, благодаря чему доменная авторизация срабатывает успешно.

Вариант 1. Явная передача доменных учетных данных в веб-сервис

Если код обязательно должен выполняться на стороне сервера 1С, но необходимо авторизоваться под конкретным доменным пользователем, передадим учетные данные явно в конструктор WSОпределения или WSПрокси.

Посмотрим на пример кода с использованием Windows-аутентификации:

ПутьКWSDL = "http://n-nb-006/sql_erp/ws/Exchange.1cws?wsdl";
ИмяПользователяОС = "DOMAIN\ivanov";
ПарольПользователяОС = "SecretPassword123";
Таймаут = 30;

// Седьмой параметр конструктора - ИспользоватьАутентификациюОС (Истина)
Определение = Новый WSОпределения(
    ПутьКWSDL,
    ИмяПользователяОС,
    ПарольПользователяОС,
    ,
    Таймаут,
    ,
    Истина
);

WSПрокси = Новый WSПрокси(
    Определение,
    "http://www.sample-uri.org/exchange",
    "Exchange",
    "ExchangeSoap"
);
WSПрокси.Пользователь = ИмяПользователяОС;
WSПрокси.Пароль = ПарольПользователяОС;

Когда параметр ИспользоватьАутентификациюОС установлен в значение Истина, платформа 1С использует переданные имя и пароль для прохождения NTLM- или Kerberos-аутентификации на веб-сервере.

Вариант 2. Настройка веб-сервера IIS для работы с проверкой подлинности

Выясним причину ошибки «Аутентификация пользователя не выполнена» со стороны веб-сервера. Если публикация базы 1С размещена на Microsoft IIS, часто возникает конфликт настроек безопасности:

1. Откроем диспетчер служб IIS и перейдем к опубликованному приложению 1С.
2. Откроем раздел Проверка подлинности (Authentication).
3. Убедимся, что включена Проверка подлинности Windows (Windows Authentication).
4. Обязательно отключим анонимную проверку подлинности (Anonymous Authentication). Если анонимный доступ включен, IIS принимает запрос без запроса учетных записей ОС, а 1С отклоняет его, если анонимный пользователь не сопоставлен с пользователем базы.
5. Если планируется использовать обычную (Basic) авторизацию с доменным логином, включим Обычную проверку подлинности (Basic Authentication). В коде 1С при этом седьмой параметр ИспользоватьАутентификациюОС передавать не требуется (устанавливается в Ложь), а логин указывается в формате ДОМЕН\Логин.

Вариант 3. Особенности работы с COM-соединением

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

V83COMConnector = Новый COMОбъект("V83.COMConnector");
// Подключение без явного указания Usr и Pwd:
Base1С = V83COMConnector.Connect("Srvr=""n-nb-006"";Ref=""sql_erp""");

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

1. Явное указание пользователя 1С: передавать в строке соединения параметры Usr и Pwd пользователя информационной базы (даже если у него настроена аутентификация операционной системы, прямое COM-подключение надежнее выполнять по логину и паролю 1С).
2. Запуск службы 1С под выделенным доменным пользователем: если цель состоит в разграничении прав на внешние ресурсы (сетевые папки, SQL), службу сервера 1С настраивают на запуск от специальной сервисной доменной учетной записи, обладающей нужными привилегиями.
3. Регистрация COM-компонента в Службах компонентов (COM+): для 64-разрядного сервера библиотеку comcntr.dll регистрируют в виде серверного приложения COM+, где на вкладке Удостоверение (Identity) жестко задается учетная запись Windows, от имени которой создается коннектор.

Вариант 4. Переход на современные протоколы авторизации

Если задача заключается в организации взаимодействия между несколькими базами 1С в корпоративной сети без сохранения паролей в открытом виде, рекомендуется отказаться от прямой NTLM-авторизации и COM-соединений в пользу современных механизмов:

1. Использование OpenID / OpenID Connect: публикация баз с единым центром авторизации (SSO). Пользователи получают прозрачный доступ во все базы без повторного ввода паролей.
2. HTTP-сервисы с токенами доступа: SOAP веб-сервисы и COM заменяются на легкие HTTP-сервисы (REST API), где авторизация выполняется по постоянным API-ключам или JWT-токенам, передаваемым в заголовках запросов (Authorization: Bearer <token>). Это полностью исключает зависимость от контекста учетной записи Windows на стороне сервера-клиента.