Как исправить ошибку «NT AUTHORITY\АНОНИМНЫЙ ВХОД» при подключении внешнего источника данных к MS SQL по Windows-аутентификации?

← На главную

При интеграции 1С с внешними базами Microsoft SQL Server через механизм Внешние источники данных разработчики часто сталкиваются с ситуацией: в файловой или локальной тестовой базе строка соединения с параметром Trusted_Connection=Yes отрабатывает без нареканий, но при переносе конфигурации на рабочий сервер 1С:Предприятия попытка обращения к таблицам внешнего источника завершается сбоем: «Ошибка входа пользователя NT AUTHORITY\АНОНИМНЫЙ ВХОД» (или в англоязычном варианте NT AUTHORITY\ANONYMOUS LOGON).

Проанализируем архитектурные особенности взаимодействия платформы 1С и MS SQL Server, выясним техническую причину такого поведения и разберем практические способы настройки подключения.

Почему возникает ошибка: архитектурные ограничения и сетевой «двойной прыжок»

Для понимания корня проблемы разберем цепочку вызовов в клиент-серверном режиме работы 1С:

Отсутствие механизма имперсонализации пользователей: Механизм «Внешние источники данных» на стороне сервера 1С функционирует исключительно внутри рабочего процесса кластера rphost. Платформа 1С не умеет передавать Windows-токен пользователя клиентской рабочей станции дальше на внешний сервер СУБД. Настройка логинов и паролей внешнего источника для каждого пользователя в режиме «1С:Предприятие» предназначена только для внутренней аутентификации средствами СУБД (SQL Server Authentication), а не для доменной сквозной аутентификации.
Проблема двойного прыжка (Kerberos Double-Hop) и откат к NTLM: Когда клиент обращается к серверу 1С, а сервер 1С пытается по Windows-авторизации обратиться к третьему узлу (внешнему серверу MS SQL), мы получаем классическую ситуацию двух сетевых переходов (Double-Hop). Если в домене Active Directory не настроено сквозное делегирование билетов Kerberos, протокол безопасности Windows не может передать учетные данные дальше первого сервера и выполняет откат на NTLM. Протокол NTLM в целях безопасности блокирует передачу учетных данных на второй сетевой узел, из-за чего удаленный MS SQL Server воспринимает входящее соединение как анонимное.
Устаревший системный ODBC-драйвер: Строка подключения вида DRIVER={SQL Server}; использует древний системный драйвер MDAC (sqlsrv32.dll). Он некорректно работает с современными механизмами SPPI/Kerberos при межсерверных вызовах и не поддерживает современные протоколы шифрования.

Способ 1. Переход на смешанную аутентификацию MS SQL (рекомендуемый вариант)

Если перед нами стоит задача разграничить доступ пользователей или обеспечить стабильную межсерверную интеграцию, самым надежным и простым решением является отказ от Trusted_Connection=Yes в пользу внутренней аутентификации средствами MS SQL Server.

Разберем по шагам, как перевести внешний источник на аутентификацию SQL:

В среде SQL Server Management Studio (SSMS) откроем свойства сервера СУБД, перейдем в раздел Безопасность (Security) и переключим режим проверки подлинности на Режим проверки подлинности SQL Server и Windows (Mixed Mode). После изменения настройки перезапустим службу SQL Server.
В разделе Безопасность -> Имена входа (Logins) создадим отдельного пользователя (или индивидуальных пользователей под каждого сотрудника) с типом Проверка подлинности SQL Server, зададим надежный пароль и назначим необходимые права на чтение/запись таблиц целевой базы данных.
В конфигураторе 1С заменим строку подключения к внешнему источнику данных, убрав флаг доверенного подключения:

Посмотрим на пример корректной строки подключения:


DRIVER={ODBC Driver 17 for SQL Server};SERVER=sql-server-name;DATABASE=TargetDatabase;UID=db_user;PWD=StrongPassword123;

Если требуется, чтобы каждый пользователь работал под своими реквизитами, мы можем воспользоваться встроенным в 1С механизмом назначения параметров аутентификации для каждого пользователя информационной базы через пункт меню Администрирование -> Параметры аутентификации внешнего источника данных.

Способ 2. Настройка единой доменной службы и ограниченного делегирования Kerberos

Если регламент безопасности предприятия категорически запрещает использование логинов SQL Server и требует исключительно авторизацию по доменным учетным записям, все серверные вызовы 1С должны идти от одной выделенной доменной службы, для которой настроена инфраструктура Kerberos.

Разберем последовательность системной настройки:

Запуск службы сервера 1С под доменной учетной записью: В оснастке services.msc на сервере 1С найдем службу Агент сервера 1С:Предприятия (ragent) и на вкладке Вход в систему переопределим запуск: вместо локальной системной учетной записи укажем специально созданную доменную учетную запись (например, DOMAIN\svc_1c_server).
Регистрация SPN для целевого SQL-сервера: Чтобы аутентификация не сбрасывалась в NTLM, администратор домена должен назначить имена участников службы (SPN) для учетной записи, под которой стартует служба MS SQL Server. Выполним команды на контроллере домена:


setspn -s MSSQLSvc/sql-server.domain.local:1433 DOMAIN\svc_sql_server
setspn -s MSSQLSvc/sql-server:1433 DOMAIN\svc_sql_server

Настройка ограниченного делегирования (Constrained Delegation): В оснастке Active Directory Users and Computers найдем учетную запись службы сервера 1С (DOMAIN\svc_1c_server), откроем ее свойства, перейдем на вкладку Делегирование (Delegation), выберем вариант Доверять этой учетной записи делегирование только указанным службам -> Использовать только Kerberos и добавим в список службу MSSQLSvc целевого сервера SQL.
Обновление ODBC-драйвера: Обязательно установим на сервер 1С актуальный 64-битный драйвер (например, ODBC Driver 17 for SQL Server или ODBC Driver 18 for SQL Server) и изменим строку подключения внешнего источника:


DRIVER={ODBC Driver 17 for SQL Server};SERVER=sql-server.domain.local;DATABASE=TargetDatabase;Trusted_Connection=Yes;

При использовании 18-й версии драйвера с самоподписанным сертификатом на стороне SQL Server добавим в строку параметр TrustServerCertificate=Yes;.

Способ 3. Выполнение запросов на клиенте через COM/ADO

Если ключевое требование задачи — фиксировать в журнале SQL Server именно конкретного доменного пользователя, сидящего за рабочим местом, встроенный механизм Внешние источники данных в клиент-серверной 1С применить не удастся из-за ограничений архитектуры платформы. В таком случае логику выборки данных необходимо выносить в клиентский контекст с обращением через ADO.

Посмотрим на пример реализации выборки на стороне клиентского приложения:


&НаКлиенте
Процедура ПолучитьДанныеИзSQL()
    
    Соединение = Новый COMОбъект("ADODB.Connection");
    Соединение.ConnectionString = "Provider=MSOLEDBSQL;Data Source=sql-server;Initial Catalog=TargetDatabase;Integrated Security=SSPI;";
    
    Попытка
        Соединение.Open();
    Исключение
        ВызватьИсключение "Не удалось подключиться к SQL: " + ОписаниеОшибки();
    КонецПопытки;
    
    Команда = Новый COMОбъект("ADODB.Command");
    Команда.ActiveConnection = Соединение;
    Команда.CommandText = "SELECT Id, Name FROM Customers";
    
    НаборЗаписей = Команда.Execute();
    
    Пока НЕ НаборЗаписей.EOF() Цикл
        // Обработка полученных полей
        Идентификатор = НаборЗаписей.Fields("Id").Value;
        Наименование  = НаборЗаписей.Fields("Name").Value;
        
        НаборЗаписей.MoveNext();
    КонецЦикла;
    
    Соединение.Close();
    
КонецПроцедуры

При выполнении этого кода в процедуре с директивой &НаКлиенте обращение к базе данных инициируется непосредственно операционной системой пользователя с рабочей станции, благодаря чему в MS SQL Server успешно передаются доменные учетные данные текущей пользовательской сессии.