Настройка бесшовной интеграции между 1С:ERP Управление предприятием и 1С:Документооборот (1С:ДО) — стандартная задача при построении единого информационного пространства предприятия. Однако при попытке совместить эту интеграцию со сквозной аутентификацией Windows (Active Directory) технические специалисты часто сталкиваются со следующей проблемой. При попытке пользователя обратиться к данным 1С:ДО из интерфейса 1С:ERP система неожиданно запрашивает логин и пароль. При вводе корректных доменных данных пользователя программа возвращает ошибку «Неверный пароль» или «Идентификация пользователя не выполнена», хотя при прямом входе в 1С:ДО через браузер сквозная авторизация отрабатывает моментально и без лишних вопросов. В процессе формирования такой ИТ-структуры применяется подбор решений для переноса данных в 1С:ERP из сторонних конфигураций.
В этой статье мы подробно разберем, почему возникает эта классическая проблема, изучим внутренние механизмы платформы 1С:Предприятие и веб-сервера IIS, а также детально рассмотрим рабочие сценарии обхода этого ограничения.
Для того чтобы понять, почему авторизация не работает «из коробки», проанализируем путь прохождения запроса при интеграции. Когда пользователь работает в тонком клиенте 1С:ERP и открывает связанный документ из 1С:ДО, происходит следующее:
rphost) инициирует HTTP- или SOAP-запрос к веб-сервису 1С:ДО (файлу DMService.1cws), опубликованному на веб-сервере IIS.Здесь и возникает ключевая проблема, известная в системном администрировании как Double Hop (двойной прыжок Kerberos). Платформа 1С:Предприятие на текущий момент не поддерживает сквозное делегирование (имперсонализацию) учетных данных Windows-пользователя с клиента на сервер при выполнении исходящих веб-запросов из серверного кода.
Поскольку запрос к IIS отправляет сервер 1С:ERP, веб-сервер IIS видит этот запрос не от имени конкретного бухгалтера или менеджера, а от имени учетной записи ОС, под которой запущена служба сервера 1С:Предприятия на сервере приложений (обычно это локальный пользователь usr1cv8). Естественно, доменная авторизация для локального пользователя usr1cv8 завершается ошибкой, и система запрашивает пароль, который не подходит, так как форматы учетных записей и контекст безопасности сервера не соответствуют ожиданиям IIS.
Ниже мы рассмотрим три надежных способа решения этой проблемы, которые позволяют сохранить удобство сквозного входа для пользователей и обеспечить стабильную работу бесшовной интеграции.
Это самый простой, безопасный и рекомендуемый архитекторами 1С способ решения проблемы. Суть метода заключается в разделении трафика: обычные пользователи будут обращаться к одной публикации с включенной Windows-авторизацией, а сервер интеграции — к другой публикации с авторизацией средствами самой 1С.
Рассмотрим по шагам, как это настроить:
Публикуем базу 1С:ДО на IIS стандартным способом (например, в виртуальный каталог /DO_Users). В настройках IIS для этого каталога отключаем «Анонимную проверку подлинности» и включаем только «Проверку подлинности Windows». Пользователи будут заходить по этой ссылке через браузер или тонкий клиент без ввода пароля.
Публикуем ту же самую базу 1С:ДО в другой виртуальный каталог на IIS (например, /DO_Integration). При публикации в конфигураторе или через утилиту командной строки обязательно публикуем только веб-сервисы, сняв галочки с публикации Web-клиента.
Открываем Диспетчер служб IIS, переходим в созданный узел DO_Integration. В разделе «Проверка подлинности» включаем «Анонимную проверку подлинности» (Anonymous Authentication) и отключаем проверку подлинности Windows. Это позволит серверу 1С:ERP беспрепятственно достучаться до веб-сервиса без блокировок на уровне веб-сервера IIS.
В настройках бесшовной интеграции на стороне 1С:ERP указываем адрес веб-сервиса, ведущий на вторую публикацию:
http://имя_сервера/DO_Integration/ws/DMService.1cws
Авторизация в данном случае будет происходить стандартным образом: в персональных настройках интеграции пользователи один раз укажут свои обычные логины и пароли от 1С:ДО (созданные внутри базы 1С), либо администратор настроит единую сервисную учетную запись для выполнения всех интеграционных запросов.
Если ваша политика безопасности требует использования исключительно Windows-аутентификации во всех соединениях, включая интеграционные веб-сервисы, мы можем настроить авторизацию на IIS от имени доменной службы 1С.
Выполним следующие шаги:
По умолчанию служба 1C:Enterprise 8.3 Server Agent работает под локальным пользователем. Нам необходимо запустить ее под специально созданной доменной учетной записью (например, DOMAIN\s-1c-service), которая обладает необходимыми правами в вашей Active Directory.
В информационной базе 1С:ДО создаем нового пользователя с именем, например, «Служба интеграции ERP». В его карточке на вкладке «Аутентификация» устанавливаем флаг «Аутентификация операционной системы» и выбираем нашего доменного пользователя DOMAIN\s-1c-service.
Этому сервисному пользователю в 1С:ДО необходимо назначить роли, достаточные для выполнения интеграционных задач (например, права на создание и чтение документов, выполнение задач и т.д.).
Теперь, когда сервер 1С:ERP обращается к публикации 1С:ДО на IIS, веб-сервер IIS успешно авторизует этот запрос под учетной записью DOMAIN\s-1c-service. 1С:ДО сопоставляет доменное имя со служебным пользователем 1С и выполняет запрос. Основной минус этого подхода — все действия интеграции в журнале регистрации 1С:ДО будут зафиксированы под одной системной учетной записью.
Если вы используете современные версии платформ (8.3.20 и выше) и новые редакции конфигураций (например, 1С:Документооборот 3.0 и 1С:ERP 2.5), разработчики предусмотрели альтернативный, очень изящный способ авторизации без использования доменных учетных записей ОС — токены авторизации JWT (JSON Web Token). Для перехода на требуемые версии программ используется автоматическое обновление и тестирование баз 1С в «тихом» режиме.
Проанализируем работу этого механизма:
При первичной авторизации пользователя в 1С:ERP система генерирует криптографически подписанный токен, содержащий информацию о пользователе. При обращении к веб-сервисам 1С:ДО этот токен передается в заголовке HTTP-запроса. Приемная сторона (1С:ДО) проверяет валидность подписи токена по заранее известному публичному ключу и автоматически авторизует пользователя без запроса паролей и без вовлечения механизмов IIS Windows Authentication. Этот способ полностью обходит проблему «двойного прыжка» Kerberos и является наиболее перспективным.
Если вы настроили Windows-авторизацию, но все равно получаете ошибку «Неверный пароль», нам потребуется заглянуть «под капот» платформы с помощью Технологического журнала (ТЖ). Это поможет понять, в каком именно формате IIS передает имя пользователя в 1С. Для диагностики и тестирования подобных механизмов взаимодействия баз пригодится инструмент для выполнения произвольных запросов через веб-сервис.
Для этого создадим на сервере приложений 1С в каталоге настроек (обычно C:\Program Files\1cv8\conf) файл конфигурации технологического журнала logcfg.xml со следующим содержимым:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-journal">
<log location="C:\v8_logs\auth_errors" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="CONN"/>
</event>
<property name="all"/>
</log>
</config>
Воспроизведем ошибку авторизации и откроем сформировавшиеся файлы логов. Нам нужно выполнить следующий анализ:
EXCP, содержащее текст: «Идентификация пользователя не выполнена. Неправильное имя или пароль пользователя».CONN.CONN свойство DstUserName2. В нем будет зафиксировано точное имя пользователя Windows в том виде, в котором его получил веб-сервер (например, DOMAIN\ivanov или ivanov@domain.local).Используя предложенные методики разделения публикаций на IIS или настройки сервисной доменной авторизации, вы сможете раз и навсегда решить проблему с вводом паролей при интеграции 1С:ERP и 1С:Документооборот, обеспечив пользователям комфортную и непрерывную работу. Для других сценариев синхронизации используется регулярный обмен данными между базами 1С по расписанию с помощью специализированного модуля.