Почему не работает доменная авторизация в браузере по HTTPS для баз 1С на IIS и как ее настроить?

← На главную

Настройка сквозной доменной авторизации (Single Sign-On, или SSO) — одна из наиболее частых и в то же время сложных задач при интеграции решений на платформе 1С:Предприятие в корпоративную ИТ-инфраструктуру. Особенно остро проблемы заявляют о себе, когда мы пытаемся опубликовать базу данных на веб-сервере IIS, переводим трафик на защищенный протокол HTTPS, а сами серверы (веб-сервер IIS и сервер приложений 1С) разносим по разным физическим или виртуальным машинам.

В такой конфигурации системные администраторы часто сталкиваются со следующей ситуацией: в тонком клиенте авторизация под доменной учетной записью проходит успешно, но при попытке войти в базу через браузер (Chrome, Edge, Firefox) по HTTPS система упорно запрашивает имя пользователя и пароль или выдает ошибку авторизации. Давайте подробно проанализируем причины этой проблемы и разберем по шагам, как настроить систему для ее стабильной работы.

Выясняем причину: анализ технологического журнала 1С

Для того чтобы понять, почему сервер 1С отвергает попытку входа, нам необходимо обратиться к технологическому журналу (ТЖ) на сервере приложений 1С. Настроим сбор событий CONN и EXCP. Проанализируем лог, зафиксированный в момент неудачной попытки входа пользователя через браузер:


32:45.982010-0,CONN,2,process=rphost,p:processName=SD,OSThread=8256,t:clientID=6952,t:applicationName=WebServerExtension,t:computerName=MOS-COD-ХХ,t:connectID=2604475,Txt=Srvr: SrcUserName1: mos_cod_1c*ХХ.LOCAL 
32:45.982012-0,CONN,2,process=rphost,p:processName=SD,OSThread=8256,t:clientID=6952,t:applicationName=WebServerExtension,t:computerName=MOS-COD-ХХ,t:connectID=2604475,Txt=Srvr: DstUserName1: НН*ХХ.local(ХХ.local\НН) 
32:45.982035-0,CONN,2,process=rphost,p:processName=SD,OSThread=8256,t:clientID=6952,t:applicationName=WebServerExtension,t:computerName=MOS-COD-ХХ,t:connectID=2604475,Txt=Srvr: DstUserName2: NT AUTHORITY\АНОНИМНЫЙ ВХОД(NT AUTHORITY\АНОНИМНЫЙ ВХОД) 
32:45.982125-0,EXCP,2,process=rphost,p:processName=SD,OSThread=8256,t:clientID=6952,t:applicationName=WebServerExtension,t:computerName=MOS-COD-ХХ,t:connectID=2604475,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr='src\VResourceInfoBaseServerImpl.cpp(1337): a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена Неправильное имя или пароль пользователя'

Обратим внимание на ключевую строку этого лога: DstUserName2: NT AUTHORITY\АНОНИМНЫЙ ВХОД. Данная запись наглядно демонстрирует нам классическую проблему сетевой безопасности Windows, известную как «двойной хоп» (Double-Hop), или ограничение делегирования учетных данных.

Рассмотрим, как это происходит физически:

Первый хоп (шаг): Пользователь со своего рабочего компьютера обращается через браузер к веб-серверу IIS. Браузер успешно передает учетные данные пользователя веб-серверу IIS. Веб-сервер понимает, кто к нему обратился.
Второй хоп (шаг): Расширение веб-сервера 1С (модуль wsisapi.dll), запущенное внутри IIS, должно передать запрос на рабочий сервер 1С (rphost), который находится на другом сервере в сети.

Если для проверки подлинности на первом шаге использовался стандартный протокол NTLM, веб-сервер IIS не имеет права передать (делегировать) учетные данные пользователя дальше на сервер 1С. В целях безопасности протокол NTLM запрещает такую трансляцию. В результате IIS вынужден обращаться к серверу 1С от имени анонимного пользователя — NT AUTHORITY\АНОНИМНЫЙ ВХОД. Сервер 1С, естественно, отклоняет такой запрос и возвращает ошибку «Идентификация пользователя не выполнена».

Для реализации сквозной авторизации в многосерверной архитектуре нам необходимо принудительно использовать протокол Kerberos и настроить доверенное делегирование в Active Directory.

Влияние протокола HTTPS и доверия к SSL-сертификатам

Часто администраторы замечают странное поведение: при обращении к тестовой базе по HTTP доменная авторизация срабатывает, но при переходе на рабочий контур с HTTPS авторизация ломается. При этом браузер выводит предупреждение о небезопасном подключении (недоверенный SSL-сертификат).

Важное правило безопасности современных браузеров: ни один современный браузер (Chrome, Edge, Firefox, Safari) из соображений безопасности никогда не передаст доменные учетные данные (ни по Kerberos, ни по NTLM), если соединение HTTPS не является доверенным. Если ваш SSL-сертификат самоподписанный, просрочен или выпущен на имя, не совпадающее с доменным именем сайта, браузер заблокирует передачу токенов авторизации.

Поэтому первым делом мы должны обеспечить полное доверие к SSL-сертификату на клиентском компьютере. Сертификат должен быть выпущен доверенным корпоративным или публичным центром сертификации (CA) и не вызывать никаких предупреждений в адресной строке браузера.

Рассмотрим пошагово весь процесс настройки сквозной аутентификации для нашей конфигурации.

Шаг 1. Настройка клиентских браузеров

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

Для браузеров на движке Chromium (Google Chrome, Microsoft Edge, Opera):

Эти браузеры используют системные настройки Windows. Нам нужно добавить адрес нашего сайта в зону местной интрасети:

Откроем классическую панель управления Windows и перейдем в Свойства интернета (или запустим команду inetcpl.cpl через Win+R).
Перейдем на вкладку Безопасность, выберем зону Местная интрасеть (Local Intranet) и нажмем кнопку Сайты.
В открывшемся окне нажмем кнопку Дополнительно.
Добавим URL-адрес нашего сайта публикации, например: https://sd.domain.local. Обратите внимание, что адрес должен быть указан строго с протоколом HTTPS и соответствовать доменному имени.
Нажмем Закрыть и применим настройки.

Для браузера Mozilla Firefox:

Firefox использует собственное хранилище настроек:

В адресной строке браузера введем about:config и согласимся с предупреждением о рисках.
В строке поиска найдем параметр network.negotiate-auth.trusted-uris.
Двойным кликом откроем его для редактирования и введем адрес нашего веб-сервера (например, https://sd.domain.local или маску домена .domain.local, чтобы разрешить авторизацию для всех внутренних ресурсов).

Шаг 2. Настройка Active Directory (SPN и Делегирование)

Чтобы протокол Kerberos мог успешно выпустить тикет для нашего веб-сайта, Active Directory должна четко знать, какая именно учетная запись отвечает за работу веб-службы по данному адресу. Для этого используется механизм регистрации SPN (Service Principal Name).

Рекомендуется запускать пул приложений IIS, в котором опубликована база 1С, под выделенной доменной сервисной учетной записью (например, domain\iis_service), а не под встроенными системными аккаунтами вроде NetworkService.

Разберем процесс регистрации SPN на контроллере домена от имени администратора домена:

Откроем командную строку от имени администратора.
Зарегистрируем имена служб с помощью утилиты setspn. Нам необходимо зарегистрировать как полное доменное имя (FQDN), так и краткое имя сервера:


setspn -s HTTP/sd.domain.local domain\iis_service
setspn -s HTTP/sd domain\iis_service

Проверить корректность регистрации SPN для нашей учетной записи можно командой:

setspn -l domain\iis_service

После успешной регистрации SPN в свойствах учетной записи пользователя iis_service в оснастке Active Directory Users and Computers (ADUC) появится важнейшая вкладка — Delegation (Делегирование). Нам нужно разрешить этой учетной записи передавать данные пользователей дальше.

Откроем свойства пользователя iis_service в ADUC.
Перейдем на вкладку Delegation.
Для обеспечения работы Kerberos выберем опцию Trust this user for delegation to any service (Kerberos only) (Доверять этому пользователю делегирование любых служб — только Kerberos).
Если политика безопасности вашей компании требует более жестких ограничений, выберите Trust this user for delegation to specified services only (Ограниченное делегирование) и укажите конкретную службу сервера 1С (класс службы MSOLAPSvc или имя компьютера, на котором запущен rphost).

Шаг 3. Настройка веб-сервера IIS

Теперь перейдем непосредственно к конфигурации веб-сервера IIS, где опубликована наша база 1С.

Во-первых, настроим пул приложений для работы под нашей сервисной учетной записью:

Откроем Диспетчер служб IIS.
Перейдем в раздел Пулы приложений (Application Pools).
Найдем пул приложений, на котором работает публикация нашей базы 1С, и откроем его Дополнительные параметры (Advanced Settings).
В поле Удостоверение (Identity) заменим стандартное значение на нашу доменную учетную запись domain\iis_service и введем пароль.

Во-вторых, скорректируем параметры аутентификации для нашего опубликованного приложения 1С:

В дереве сайтов IIS выберем наше опубликованное приложение (например, sd).
В центральной части окна откроем раздел Аутентификация (Authentication).
Отключим Анонимную проверку подлинности (Anonymous Authentication). Это критически важно! Если она включена, IIS будет пытаться обрабатывать запросы анонимно, игнорируя попытки браузера передать доменные токены.
Включим Проверку подлинности Windows (Windows Authentication).

В-третьих, настроим провайдеры безопасности Windows-аутентификации:

Выделим строку Проверка подлинности Windows и в правой панели действий нажмем Поставщики (Providers).
Убедимся, что на первом месте в списке стоит поставщик Negotiate (он отвечает за Kerberos-аутентификацию), а под ним — NTLM. Наличие поставщика Negotiate обязательно для реализации сценария без двойного хопа.
Закроем окно поставщиков и в той же правой панели выберем Дополнительные параметры (Advanced Settings).
Внимание: Если пул приложений работает под доменной учетной записью (как мы настроили выше), снимите флаг Включить проверку подлинности в режиме ядра (Enable Kernel-mode authentication). Если этот режим включен, IIS пытается расшифровывать Kerberos-тикеты с использованием системной учетной записи самого сервера (компьютера в домене), а не нашей сервисной учетной записи пула приложений, что приведет к ошибкам расшифровки и сбросу авторизации.

Шаг 4. Проверка и диагностика работоспособности

После выполнения всех настроек обязательно перезапустим службу IIS (выполнив команду iisreset в командной строке) и перезапустим рабочие процессы сервера 1С.

Для диагностики успешности прохождения Kerberos-аутентификации на клиентском компьютере мы можем воспользоваться встроенной утилитой командной строки klist:

Закроем все окна браузера.
Откроем командную строку на клиентском ПК и очистим текущие Kerberos-тикеты командой: klist purge.
Откроем браузер и перейдем по адресу нашей базы https://sd.domain.local. Авторизация должна пройти мгновенно и без запроса пароля.
Вернемся в командную строку и выполним команду: klist.
В списке полученных билетов мы должны увидеть тикет, выданный для нашего веб-ресурса, вида HTTP/sd.domain.local. Это будет прямым доказательством того, что авторизация успешно прошла по протоколу Kerberos, проблема двойного хопа решена, а пользователь успешно вошел в систему под своей доменной учетной записью.