При интеграции различных информационных баз 1С часто возникает необходимость настроить сквозную авторизацию. Использование явной передачи логинов и паролей в открытом виде внутри программного кода снижает уровень информационной безопасности и усложняет администрирование системы (например, при регулярной смене паролей пользователей в домене Active Directory). Оптимальным решением является использование встроенной аутентификации операционной системы (Windows Authentication) для COM-соединений. Подобный подход востребован, чтобы автоматизировать регулярный обмен данными между базами 1С без изменения самих конфигураций.
В этой статье мы подробно разберем, как правильно составить строку подключения, настроить системные компоненты DCOM на сервере и клиенте, обойти классические ошибки авторизации и решить сложную архитектурную проблему «двойного прыжка» (Double-Hop) при вызове соединения на стороне сервера.
Для того чтобы платформа 1С:Предприятие при создании COM-соединения попыталась авторизоваться под учетной записью текущего пользователя операционной системы, в строку подключения необходимо передать специальный параметр WA (Windows Authentication). Рассмотрим синтаксис строки подключения для клиент-серверного варианта базы данных:
СтрокаПодключения = "Srvr=""ИмяСервера1С""; Ref=""ИмяИБ""; WA+;";
// Альтернативный вариант синтаксиса:
// СтрокаПодключения = "Srvr=""ИмяСервера1С""; Ref=""ИмяИБ""; WA=1;";
Обратим внимание на важную деталь: параметры Usr (Пользователь) и Pwd (Пароль) в строке подключения должны полностью отсутствовать. Если мы попытаемся передать их пустыми в сочетании с Windows-аутентификацией, система может выдать ошибку «Неверное имя пользователя или пароль».
Полный листинг инициализации подключения на клиенте выглядит следующим образом:
СтрокаПодключения = "Srvr=""Server1C""; Ref=""Trade_Base""; WA+;";
Попытка
Соединитель = Новый COMObject("V83.COMConnector");
мСоединение = Соединитель.Connect(СтрокаПодключения);
Сообщить("Соединение успешно установлено!");
Исключение
ВызватьИсключение "Не удалось подключиться к базе: " + ОписаниеОшибки();
КонецПопытки;
Если мы запускаем этот код на клиентском компьютере в файловом или клиент-серверном варианте, платформа автоматически возьмет токен безопасности текущего пользователя Windows, под которым открыта активная сессия операционной системы, и передаст его целевой базе данных для проверки прав. После успешного подключения можно автоматически сравнить бухгалтерские и налоговые проводки между двумя базами для выявления расхождений.
Часто программисты сталкиваются с ситуацией, когда код, выполняемый на клиенте, завершается ошибкой авторизации, хотя в настройках пользователя 1С установлена галка «Аутентификация операционной системы» и указан корректный доменный пользователь вида DOMAIN\User. Причиной этой проблемы часто является некорректная настройка суррогатного процесса COM+ на компьютере. Для решения проблем работы 32-битного COM-соединения и настройки суррогатного процесса пригодится руководство по настройке приложения COM+.
В операционных системах Windows (особенно 64-битных версиях) для корректной работы 32-битной библиотеки comcntr.dll администраторы часто создают выделенное приложение в службе компонентов (DCOM). Проанализируем, как настройки этого приложения влияют на права доступа:
dcomcnfg в строке выполнения Windows).Именно здесь кроется разгадка проблемы, описанной во многих обращениях разработчиков. На этой вкладке доступны три ключевых режима запуска процесса:
WA+ подключение к целевой базе ВСЕГДА будет выполняться от имени этого жестко прописанного пользователя, а не от имени реального сотрудника, нажавшего кнопку в 1С!COMObject("V83.COMConnector"). На клиенте им станет текущий пользователь Windows.Также важно проверить вкладку Безопасность (Security) в свойствах приложения COM+. Убедимся, что уровень авторизации установлен в значение «Пакет» (Packet), а права на запуск и активацию предоставлены группе пользователей, которым разрешено работать с интеграцией.
Перенесем наше внимание на серверные вызовы. Очень часто возникает задача: выполнить ресурсоемкую операцию получения данных через COM-соединение в фоне или внутри серверного общего модуля (директива &НаСервере), но при этом авторизоваться под учетной записью доменного пользователя, запустившего клиентское приложение.
Выясним причину, почему обычный вызов WA+ на сервере не сработает так, как ожидает разработчик. При переходе выполнения кода с клиента на сервер контекст безопасности кардинально меняется. Код на сервере выполняется внутри рабочего процесса 1С (rphost.exe). По умолчанию служба сервера 1С:Предприятие работает под специальной локальной или доменной технической учетной записью (например, USR1CV8 или NetworkService).
Следовательно, при попытке выполнить следующий код на сервере:
&НаСервере
Процедура ВыполнитьПодключениеНаСервере()
СтрокаПодключения = "Srvr=""ServerDB""; Ref=""TargetDB""; WA+;";
Соединитель = Новый COMObject("V83.COMConnector");
// Подключение произойдет под учетной записью службы сервера 1С!
мСоединение = Соединитель.Connect(СтрокаПодключения);
КонецПроцедуры
Целевая база данных попытается авторизовать пользователя DOMAIN\USR1CV8. Если такого пользователя нет в списке пользователей целевой базы с включенной ОС-аутентификацией, мы получим закономерный отказ в доступе. Передать пароль текущего пользователя с клиента на сервер невозможно по соображениям безопасности платформы.
Когда нам действительно необходимо, чтобы сервер 1С обратился к другой системе от лица авторизованного на клиенте доменного пользователя, мы сталкиваемся с классической проблемой ограничения протокола NTLM, известной как «двойной прыжок». NTLM не позволяет передавать учетные данные пользователя дальше первого узла (от Клиента к Серверу 1С — это первый прыжок, а от Сервера 1С к Серверу СУБД или другой базе по COM — это уже второй прыжок).
Для решения этой задачи в инфраструктуре Active Directory необходимо настроить ограниченное делегирование Kerberos (Kerberos Constrained Delegation). Разберем этот процесс по шагам:
Служба сервера 1С не может выполнять делегирование Kerberos, если она запущена под локальной учетной записью (например, LocalSystem или локальный USR1CV8). Необходимо создать в Active Directory выделенную сервисную учетную запись (например, DOMAIN\usr1cv8-service) и настроить запуск службы «1C:Enterprise 8.3 Server Agent» от ее имени.
Для того чтобы контроллер домена понимал, к какой службе обращаются пользователи, необходимо зарегистрировать имена-идентификаторы служб (SPN) для созданной учетной записи. Выполним в командной строке контроллера домена от имени администратора следующие команды:
setspn -S 1CV8/ИмяСервера1С.domain.local DOMAIN\usr1cv8-service
setspn -S 1CV8/ИмяСервера1С DOMAIN\usr1cv8-service
Рекомендуется также зарегистрировать SPN для СУБД (например, MS SQL Server), если обращение к базам данных происходит в рамках того же домена:
setspn -S MSSQLSvc/ИмяСервераБД.domain.local:1433 DOMAIN\sql-service
Откроем консоль администрирования серверов 1С:Предприятия. В свойствах нашего рабочего сервера найдем поле «Имя службы (SPN) сервера 1С:Предприятия» и внесем туда зарегистрированное ранее значение: 1CV8/ИмяСервера1С.domain.local.
Теперь необходимо разрешить доменной учетной записи сервера 1С олицетворять пользователей (выполнять impersonation) при обращении к целевым ресурсам:
usr1cv8-service.После применения этих настроек сервер 1С получит легитимное право запрашивать у контроллера домена временные тикеты безопасности от лица подключенных клиентов и прозрачно использовать их при установке COM-соединений с параметром WA+.
Рассматривая архитектурные особенности COM-соединений, важно отметить, что данная технология является устаревшей и привязанной исключительно к операционной системе Windows. Если на вашем предприятии планируется перевод серверов 1С на операционную систему Linux, COM-соединения полностью перестанут функционировать. В этом случае для миграции используется раздел с решениями по переносу данных 1С по тарифу PRO.
В качестве современной и более надежной альтернативы рассмотрим использование встроенных HTTP-сервисов 1С:
HTTPСоединение. При этом авторизация текущего доменного пользователя транслируется на уровне веб-сервера полностью автоматически и безопасно.Такой подход избавляет от необходимости сложной настройки системного реестра Windows, исключает утечки памяти, свойственные COM-соединениям, и делает ИТ-ландшафт вашей компании кроссплатформенным. Для практической реализации переноса данных с использованием технологий COM и HTTP подойдёт обработка для универсального переноса данных между конфигурациями.