Как настроить сквозную Windows-авторизацию при подключении 1С к базе данных MSSQL без ввода логина и пароля?

← На главную

При интеграции систем часто возникает необходимость выгрузки или чтения данных из внешних баз под управлением СУБД Microsoft SQL Server. Традиционный подход с жестким прописыванием логина и пароля (SQL Server Authentication) в коде 1С или в константах сопряжен с серьезными рисками информационной безопасности. Если учетные данные хранятся в открытом виде в строке подключения, любой разработчик или администратор с доступом к коду может их скомпрометировать. Выходом из этой ситуации является использование сквозной (доменной/Windows) авторизации.

В этой статье мы подробно разберем, как правильно реализовать беспарольное подключение к MSSQL из среды «1С:Предприятие», проанализируем синтаксис строк подключения, изучим влияние контекста выполнения кода и рассмотрим сложные архитектурные нюансы, такие как проблема «двойного прыжка» (Double-Hop) и особенности работы на серверах под управлением ОС Linux.

Шаг 1. Понимание сути сквозной авторизации

Сквозная авторизация (или Windows Authentication / Integrated Security) основывается на доверительных отношениях в домене Active Directory. Вместо передачи пары «логин-пароль» клиент отправляет СУБД маркер безопасности текущего процесса операционной системы. MSSQL проверяет этот маркер через контроллер домена и сопоставляет его со списком разрешенных пользователей.

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

Шаг 2. Формирование строки подключения и выбор драйвера

Для создания подключения из 1С обычно используется COM-объект ADODB.Connection. Чтобы СУБД поняла, что нужно использовать текущие учетные данные операционной системы, из строки подключения необходимо полностью исключить параметры User ID (или UID) и Password (или PWD), заменив их на специальный параметр.

Рассмотрим синтаксис строки подключения в зависимости от используемого драйвера. Обратите внимание, что устаревший драйвер SQLOLEDB (Microsoft OLE DB Provider for SQL Server) официально не рекомендуется к использованию корпорацией Microsoft. Вместо него следует применять современный драйвер MSOLEDBSQL (Microsoft OLE DB Driver for SQL Server).

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

Вариант 1. Использование современного драйвера MSOLEDBSQL (Рекомендуется)


// Формируем строку подключения с использованием Integrated Security
СтрокаПодключения = "Provider=MSOLEDBSQL;Integrated Security=SSPI;Initial Catalog=ИмяВнешнейБазы;Data Source=ИмяСервераБД;";

Вариант 2. Использование классического драйвера SQLOLEDB (Устаревший)


// В устаревшем драйвере также используется Integrated Security=SSPI
СтрокаПодключения = "Provider=SQLOLEDB.1;Integrated Security=SSPI;Initial Catalog=ИмяВнешнейБазы;Data Source=ИмяСервераБД;";

Вариант 3. Использование ODBC-драйвера

При использовании ODBC-соединений (например, через системный DSN) вместо Integrated Security=SSPI часто используется синоним Trusted_Connection=yes:


СтрокаПодключения = "Driver={ODBC Driver 17 for SQL Server};Server=ИмяСервераБД;Database=ИмяВнешнейБазы;Trusted_Connection=yes;";

Шаг 3. Учет контекста выполнения кода в 1С (Главный "подводный камень")

Настройка строки подключения — это лишь вершина айсберга. Самая частая ошибка разработчиков заключается в непонимании того, в каком контексте и под чьим именем запускается сессия соединения с MSSQL. Выясним, под кем именно будет выполняться запрос в различных режимах работы 1С:

Файловый режим (или выполнение на клиенте): Если код выполняется непосредственно на стороне тонкого или толстого клиента (директива &НаКлиенте) либо база работает в файловом режиме, авторизация на сервере MSSQL произойдет под учетной записью текущего Windows-пользователя, который запустил сессию 1С на своем компьютере. В этом случае достаточно предоставить права в MSSQL именно этому доменному пользователю.
Клиент-серверный режим (выполнение на сервере 1С): Если код выполняется на стороне сервера 1С (директива &НаСервере, фоновые или регламентные задания), запрос к внешней СУБД пойдет не от имени пользователя, сидящего за компьютером. Подключение инициирует сама служба операционной системы «Агент сервера 1С:Предприятия».
По умолчанию служба сервера 1С устанавливается под локальной учетной записью (например, USR1CV8 или USR1CV83). Поскольку эта учетная запись является локальной для сервера приложений 1С, удаленный сервер MSSQL отклонит попытку подключения. Чтобы решить эту проблему, выполните следующие действия:
- Создайте в домене специальную техническую учетную запись (например, DOMAIN\usr1cv8_service).
- Запустите службу «Агент сервера 1С:Предприятия» на сервере приложений от имени этой доменной учетной записи.
- На сервере MSSQL предоставьте права доступа (Login и соответствующие роли к базе данных) именно этой учетной записи DOMAIN\usr1cv8_service.

Рассмотрим пример кода на встроенном языке 1С, который безопасно инициализирует подключение к СУБД с обработкой возможных исключений:


&НаСервере
Процедура ПодключитьсяКВнешнейБДНаСервере()
    
    // Инициализируем COM-объект для работы с ADO
    Попытка
        Соединение = Новый COMОбъект("ADODB.Connection");
    Исключение
        ЗаписатьЛогОшибок("Не удалось создать объект ADODB.Connection. Возможно, не установлены компоненты MDAC/WDAC.");
        Возврат;
    КонецПопытки;
    
    // Обратите внимание: параметры User ID и Password не указываются!
    // Авторизация произойдет под доменной учетной записью службы сервера 1С
    СтрокаПодключения = "Provider=MSOLEDBSQL;Integrated Security=SSPI;Initial Catalog=ExternalProduction;Data Source=SQL-SERVER-01;";
    
    Соединение.ConnectionTimeout = 15;
    
    Попытка
        Соединение.Open(СтрокаПодключения);
        
        // Выполняем тестовый запрос
        ТекстЗапроса = "SELECT TOP 1 [ID], [Name] FROM [dbo].[Partners]";
        Рекордсет = Соединение.Execute(ТекстЗапроса);
        
        Пока Рекордсет.EOF() = 0 Цикл
            // Обработка полученных данных
            ИмяПартнера = Рекордсет.Fields("Name").Value;
            // Переходим к следующей записи
            Рекордсет.MoveNext();
        КонецЦикла;
        
        // Закрываем соединения
        Рекордсет.Close();
        Соединение.Close();
        
        Сообщить("Подключение и чтение данных выполнены успешно!");
        
    Исключение
        ИнформацияОбОшибке = ОписаниеОшибки();
        ЗаписатьЛогОшибок("Ошибка при работе с MSSQL: " + ИнформацияОбОшибке);
        
        // Гарантируем закрытие соединения при возникновении ошибки
        Если Соединение.State = 1 Тогда
            Соединение.Close();
        КонецЕсли;
    КонецПопытки;
    
КонецПроцедуры

Шаг 4. Решение проблемы «двойного прыжка» (Double-Hop) и настройка Kerberos

Иногда бизнес-требования диктуют следующую логику: необходимо, чтобы сервер 1С подключался к MSSQL не под единой технологической учетной записью службы, а делегировал права конкретного Windows-пользователя, который в данный момент работает в программе 1С. В таком сценарии вы гарантированно столкнетесь с фундаментальным ограничением безопасности Windows, известным как проблема «двойного прыжка» (Double-Hop).

При стандартной конфигурации Windows запрещает передавать учетные данные пользователя «по цепочке» дальше одного узла. Цепочка выглядит так: Клиентский компьютер (Прыжок 1) -> Сервер приложений 1С (Прыжок 2) -> Сервер MSSQL. При попытке выполнить такой запрос без дополнительной настройки вы получите ошибку авторизации: Ошибка входа пользователя NT AUTHORITY\АНОНИМНЫЙ ВХОД (или Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON').

Для того чтобы решить эту проблему, необходимо настроить сквозную **Kerberos-делегируемую аутентификацию** в вашем домене Active Directory. Разберем по шагам действия, которые должен выполнить системный администратор:

Регистрация SPN (Service Principal Name): Для доменных учетных записей, под которыми работают службы сервера 1С и сервера MSSQL, необходимо зарегистрировать имена-идентификаторы служб с помощью утилиты командной строки setspn. Например:
```
setspn -A MSSQLSvc/sqlserver.domain.local:1433 domain\sql_service_account
setspn -A 1CV8Server/1cserver.domain.local:1540 domain\1c_service_account
```
Настройка доверия делегирования (Delegation): В оснастке Active Directory Users and Computers (ADUC) откройте свойства учетной записи службы 1С и на вкладке Delegation (Делегирование) выберите опцию «Trust this user for delegation to any service (Kerberos only)» или настройте ограниченное делегирование (Constrained Delegation) для конкретной службы MSSQLSvc целевого сервера баз данных.

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

Шаг 5. Специфика серверов 1С на операционной системе Linux

В современных реалиях серверная часть «1С:Предприятия» всё чаще разворачивается на базе Linux-дистрибутивов (Ubuntu, Astra Linux, RED OS), в то время как внешняя база MSSQL по-прежнему работает под управлением ОС Windows. Так как Linux «из коробки» не поддерживает механизмы безопасности Windows-домена, для реализации сквозной авторизации требуется провести дополнительную системную интеграцию:

Ввод Linux-сервера в домен Active Directory: Сервер с ОС Linux должен быть корректно интегрирован в Windows-домен (например, с использованием SSSD или Winbind).
Настройка Kerberos-клиента: На сервере Linux необходимо настроить конфигурационный файл /etc/krb5.conf, указав в нем параметры вашего домена (KDC, admin_server).
Генерация keytab-файла: На контроллере домена Active Directory создается файл ключевой таблицы (keytab), содержащий секретные ключи для учетной записи службы 1С. Этот файл переносится на Linux-сервер и подключается к демону авторизации.
Инициализация тикета: Для пользователя usr1cv8, под которым в Linux запускается сервер 1С, настраивается автоматическое получение доменного Kerberos-тикета с помощью утилиты kinit при старте операционной системы.

При такой схеме драйвер ODBC на стороне Linux сможет беспрепятственно запрашивать авторизацию у Windows-сервера MSSQL по протоколу Kerberos без прямой передачи паролей.

Шаг 6. Использование штатного механизма «Внешние источники данных»

Если вы хотите избежать написания кода работы с COM-объектами и повысить производительность работы с данными СУБД, отличным решением будет использование встроенного объекта метаданных платформы «1С:Предприятие» — **Внешние источники данных**.

Проанализируем процесс настройки:

В дереве метаданных конфигурации перейдите в ветку «Внешние источники данных» и добавьте новый объект.
В свойствах созданного источника откройте диалог настройки строки подключения.
Установите флаг «Использовать аутентификацию операционной системы» (платформа автоматически скроет поля ввода имени пользователя и пароля и сама сформирует корректные параметры Integrated Security=SSPI или Trusted_Connection=yes в зависимости от выбранного провайдера данных).
При работе с таблицами внешнего источника учитывайте, что все запросы в клиент-серверном варианте платформы 1С транслируются через сервер приложений. Соответственно, доступ к таблицам будет осуществляться в контексте учетной записи, под которой функционирует служба сервера 1С (как подробно описано в Шаге 3).

Использование этого штатного механизма позволяет разработчикам манипулировать внешними таблицами СУБД с помощью стандартных запросов 1С, используя конструкции языка запросов платформы и сохраняя при этом высокий уровень информационной безопасности инфраструктуры.