Как настроить доменную авторизацию в 1С, если веб-сервер IIS и сервер приложений находятся на разных компьютерах?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Проанализируем причину этого поведения. Данная проблема известна как эффект «двойного прыжка» (Double Hop). При использовании стандартного протокола NTLM веб-сервер получает учетные данные пользователя, но не имеет права передать их дальше — на сервер приложений 1С. Для решения этой задачи нам необходимо перейти на использование протокола Kerberos и настроить делегирование полномочий в домене Active Directory.

Шаг 1. Подготовка учетных записей служб

Прежде всего, выясним, под какими учетными записями работают наши службы. Для корректной настройки Kerberos крайне рекомендуется использовать доменные учетные записи, а не локальные системные профили, при этом важно обеспечить безопасное хранение паролей этих служб (поможет безопасное хранение и управление паролями в 1С). Проверим следующие настройки:

  1. Сервер 1С: Служба 1C:Enterprise 8.3 Server Agent должна запускаться от имени доменной учетной записи (например, DOMAIN\usr1cv8), что важно учитывать и при установке лицензий на сервер.
  2. Веб-сервер IIS: Пул приложений, в котором опубликована база 1С, также должен работать под доменной учетной записью (например, DOMAIN\usriis) или под NetworkService.

Важный момент: если вы используете NetworkService, в настройках Active Directory делегирование нужно будет настраивать для учетной записи самого компьютера (Computer Account), а для контроля работы сервера (удобно через мониторинг сбоев и управление сеансами в Telegram) можно использовать приложение для управления сеансами.

Шаг 2. Регистрация имен сервисов (SPN)

Для того чтобы протокол Kerberos понимал, к какому сервису обращается клиент, мы должны зарегистрировать Service Principal Names (SPN). Это делается с помощью консольной утилиты setspn от имени администратора домена.

Разберем команды для регистрации. Предположим, наш веб-сервер называется 1c-web, а сервер 1С — 1c-app.

Сначала зарегистрируем SPN для веб-сервера (привязываем к учетке пула IIS):


setspn -S HTTP/1c-web DOMAIN\usriis
setspn -S HTTP/1c-web.domain.local DOMAIN\usriis

Затем зарегистрируем SPN для сервера приложений 1С (порт по умолчанию 1540), где работают рабочие процессы rphost:


setspn -S 1CV8/1c-app:1540 DOMAIN\usr1cv8
setspn -S 1CV8/1c-app.domain.local:1540 DOMAIN\usr1cv8

Проверим корректность регистрации командой setspn -L DOMAIN\username. Мы должны увидеть созданные записи в списке.

Шаг 3. Настройка делегирования в Active Directory

Теперь нам нужно разрешить веб-серверу передавать (делегировать) аутентификационные данные пользователя серверу 1С. Посмотрим, как это сделать в оснастке Active Directory Users and Computers:

  1. Найдем учетную запись, под которой запущен пул приложений IIS (DOMAIN\usriis).
  2. Откроем её свойства и перейдем на вкладку Делегирование (Delegation).
  3. Выберем вариант «Доверять этому пользователю делегирование только определенным службам» (Trust this user for delegation to specified services only) — это так называемое ограниченное делегирование (Constrained Delegation), которое более безопасно.
  4. Установим переключатель на «Использовать любой протокол аутентификации» (Use any authentication protocol).
  5. Нажмем кнопку «Добавить», затем «Пользователи и компьютеры», и выберем учетную запись сервера 1С (DOMAIN\usr1cv8).
  6. В списке доступных служб выберем ту, которую мы регистрировали в Шаге 2 (тип 1CV8).

Проделаем аналогичные действия для учетной записи сервера 1С, если планируется дальнейшая передача данных (например, к SQL-серверу).

Шаг 4. Тонкая настройка IIS

Перейдем к настройкам самого веб-сервера. Откроем Диспетчер служб IIS и выберем нашу публикацию 1С. Нам нужно настроить раздел Проверка подлинности (Authentication):

  1. Включим Проверку подлинности Windows (Windows Authentication). Все остальные методы (включая анонимный вход) должны быть отключены.
  2. Зайдем в «Поставщики» (Providers) для Windows Authentication. Убедимся, что Negotiate находится на первом месте. Это заставит браузер сначала пытаться использовать Kerberos.
  3. Зайдем в «Расширенные параметры» (Advanced Settings). Проанализируем состояние опции Проверка подлинности в режиме ядра (Kernel-mode authentication). В распределенных средах с использованием доменных учеток служб ее часто рекомендуют отключить, чтобы избежать конфликтов с SPN.

Шаг 5. Настройка файла публикации default.vrd

Файл default.vrd содержит параметры подключения веб-клиента к серверу 1С. Нам нужно убедиться, что в нем разрешена доменная авторизация. Проверим наличие и значение атрибута authenticationExtension в корневом теге point или параметрах ws.

Пример структуры файла с включенной поддержкой:


<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="/MyBase"
       ib="Srvr=1c-app;Ref=MyBase;">
    <standardOdata enable="true" reuseSessions="autouse"/>
</point>

Убедимся, что в самой информационной базе 1С для пользователей, которым нужен вход через домен, установлена галочка «Аутентификация операционной системы» и указано их доменное имя в формате DOMAIN\UserName — для этого поможет обработка для принудительного завершения сеансов пользователей.

Шаг 6. Настройки клиентской части (Браузер)

Если после всех настроек сервер всё равно запрашивает пароль, значит, браузер клиента не доверяет веб-серверу настолько, чтобы автоматически отдавать ему данные текущего сеанса Windows. Рассмотрим, как это исправить:

  1. Добавим адрес нашего сервера (например, http://1c-web) в зону «Местная интрасеть» (Local Intranet) в настройках свойств браузера (Internet Options).
  2. В настройках безопасности этой зоны убедимся, что в разделе «Проверка подлинности пользователя» выбрано «Автоматический вход в сеть только в зоне интрасети».
  3. Если используется Chrome или Edge, может потребоваться настройка групповой политики AuthServerAllowlist, где нужно явно указать маску имени сервера для передачи учетных данных.

Выясним причину, почему при обращении по localhost всё работало: Windows по умолчанию считает localhost доверенным узлом и всегда пытается использовать текущую учетную запись. При переходе к имени хоста 1c-web вступают в силу политики безопасности интрасети, поэтому добавление в доверенные узлы является обязательным шагом.

Следуя этой инструкции и последовательно настроив Kerberos, делегирование и параметры IIS, мы добьемся стабильной сквозной авторизации в распределенной среде 1С.

← На главную