Как исправить ошибку HTTP Error 401.1 Unauthorized при обращении к веб-сервису 1С на IIS?

← На главную

При публикации и использовании веб-сервисов 1С на веб-сервере Microsoft IIS разработчики и системные администраторы часто сталкиваются с ситуацией, когда локально на сервере сервис открывается без проблем, а при обращении с другого компьютера возникает ошибка HTTP Error 401.1 - Unauthorized (или постоянный запрос логина и пароля, который не принимается сервером). Разберем по шагам, почему возникает эта проблема и как правильно настроить авторизацию.

Проанализируем механизм обработки запроса: при отправке вызова к веб-сервису клиент передает учетные данные пользователя 1С в заголовке авторизации. Если веб-сервер IIS настроен некорректно, он перехватывает этот заголовок и пытается сопоставить логин и пароль с учетными записями операционной системы Windows, а не передает их расширению 1С. В результате IIS возвращает ошибку 401.1 Logon Failed.

Причина 1. Конфликт типов аутентификации в IIS

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

Выполним правильную настройку модулей проверки подлинности в диспетчере служб IIS:

Откроем Диспетчер служб IIS (Internet Information Services Manager).
В дереве подключений слева найдем наш сайт и виртуальный каталог опубликованной базы 1С.
В центральной части перейдем в раздел Проверка подлинности (Authentication).
Установим состояние Включено (Enabled) только для пункта Анонимная проверка подлинности (Anonymous Authentication).
Отключим все остальные типы проверки подлинности: Проверка подлинности Windows (Windows Authentication), Обычная проверка подлинности (Basic Authentication) и Дайджест-проверка подлинности должны иметь статус Отключено (Disabled).
Перезапустим веб-сервер IIS или соответствующий пул приложений.

После отключения проверки подлинности Windows сервер IIS перестанет перехватывать HTTP-заголовок Authorization и передаст его напрямую модулю расширения веб-сервера 1С (wsisapi.dll), который успешно авторизует пользователя информационной базы.

Причина 2. Проверка прав пользователя в базе 1С

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

Откроем конфигурацию в режиме Конфигуратор.
Перейдем в ветку метаданных Web-сервисы и найдем целевой сервис.
Проверим в назначенных пользователю ролях наличие права Использование (Use) для данного веб-сервиса.
Убедимся, что для пользователя отключена аутентификация по протоколу OpenID, если сервис ожидает стандартную HTTP Basic-аутентификацию.

Причина 3. Передача авторизационных данных в коде 1С

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

Посмотрим на пример правильного создания прокси через объект WSОпределения:


АдресWSDL = "http://server-name/base_ws/ws/WebServiceName.1cws?wsdl";
ИмяПользователя = "WSUser";
ПарольПользователя = "StrongPassword123";

// Загружаем WSDL с явным указанием учетных данных
Определения = Новый WSОпределения(АдресWSDL, ИмяПользователя, ПарольПользователя);

URIПространства = "http://www.sample-ws.org";
ИмяСервиса = "WebServiceName";

// Создаем прокси с передачей авторизации
Прокси = Новый WSПрокси(Определения, URIПространства, ИмяСервиса, ИмяСервиса + "Soap", , ИмяПользователя, ПарольПользователя);
Результат = Прокси.ВыполнитьОперацию();

Если в конфигурации используется статическая ссылка из дерева метаданных (объект WSСсылки), учетные данные необходимо передавать при инициализации прокси:


Прокси = WSСсылки.ИмяСервиса.СоздатьWSПрокси(
    "http://www.sample-ws.org",
    "WebServiceName",
    "WebServiceNameSoap",
    ,
    "WSUser",
    "StrongPassword123"
);
Результат = Прокси.ВыполнитьОперацию();

Причина 4. Настройка прав файловой системы NTFS и пула приложений

Рассмотрим параметры доступа к файлам публикации 1С на уровне операционной системы:

В диспетчере IIS откроем параметры Анонимной проверки подлинности для публикации и выберем пункт Удостоверение пула приложений (Application pool identity).
В проводнике откроем свойства каталога, где расположен файл публикации default.vrd.
На вкладке Безопасность предоставим права на чтение и выполнение группе IIS_IUSRS и учетной записи пула приложений (например, IIS AppPool\DefaultAppPool).
Убедимся, что аналогичные права на чтение имеются у веб-сервера к каталогу платформы bin, содержащему библиотеки 1С.

Причина 5. Авторизация через файл публикации default.vrd

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

Откроем файл default.vrd в текстовом редакторе и дополним атрибут ib учетными данными специального служебного пользователя:


<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       base="/base_ws"
       ib="Srvr=db-server;Ref=base_ws;Usr=WSUser;Pwd=StrongPassword123;">
    <ws>
        <point name="WebServiceName"
               alias="WebServiceName.1cws"
               enable="true"/>
    </ws>
</point>

При таком подходе веб-сервер подключается к базе от имени предопределенного пользователя WSUser, и запросы авторизации клиентам не выдаются.