Внешний источник данных. MS SQL. Windows аутентификация #784402

Добрый день. Может знает как вылечить. Есть база ms sql, в которой заведен пользователь с доменной аутентификацией. Подключаюсь строкой: DRIVER={SQL Server};SERVER=****;DATABASE=***;Trusted_Connection=Yes; При подключении вылезает ошибка: "Ошибка входа пользователя NT AUTHORITYАНОНИМНЫЙ ВХОД". В локальной базе естественно проблем нет. Может знает кто как вылечить?

в строке подключения указывай юзверя и пароль

Windows аутентификация. Какой пользователь и пароль?

дык ты пытаешься зайти с системной учетной записью, тебе оутлуп. Заведи смешанную авторизацию в скуле, делов то. Будешь задавать нормального юзверя и пароль.

Это решение - крайняя мера. Понимаю, что простое, ну а если нужно, что бы каждый под своей доменной учеткой работал?

А не могли бы вы выражаться яснее? Откуда и куда "подключаюсь"? О какой "локальной" базе речь? А проблема в "не локальной" базе? А подключение идет с сервера или с клиента?

1. Есть база ms sql 2. Есть база 1С, расположенная на сервере 1с предприятия 3. Есть локальная файловая база. при подключении из 3 к 1, все работает при подключении из 2 к 1 не работает

Еще раз, пользуюсь внешними источниками данных. Как оно там сделано, я без понятия. Судя по тому что выдает ошибку, дело происходит на стороне сервера 1с предприятия.

Имя пользователя и пароль Windows

Под каким пользователем запущена служба 1с? Должна быть под тем же доменным, под которым надо входить в скуль - тогда будет работать. Но лучше используется смешанную авторизацию.

ну так из серверной базы авторизация будет от пользователя под которым работает рабочий процесс сервера 1С

Об этом я догадываюсь, но не понятно а) зачем во внешних источниках есть настройки для каждого пользователя, и вообще доменная аутентификация. б) Ошибка была бы типа "Нет доступа для пользователя доменпользователь", а тут выскакивает анонимная аутентификация

Доменная аутентификация она же сквозная, то есть один раз вошел в домен, потом вводить ничего не надо.

кто там в домен вошел, системная учетная запись сервера 1с?

Че паришься ? Ну запусти службу агента 1с от имени пользователя, у которого есть права на вход в скуль и привет.

Ну у меня их будет несколько десятков разных, поэтому и парюсь. Я вот думаю я где-то косячу или 1С просто не доделали.

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

так на сервере же соединение создается

Ну ну, не понимаю. То, что оно так реализовано, не означает что это единственно правильное решение. Это я так воздух сотрясаю. Ладно, всем спасибо за соучастие.

В 1С хорошее и логичное (с точки зрения использования) решение Windows-авторизации ... Ты просто в Eset Nod не видел

В продолжение Завели пользователя в базу sql, под которым службы сервера 1с подняты. Завели хорошо, через ADO на сервере коннект есть. Но вот внешние источники данных так и не заработали. Так что, хорошо, может и хорошо (мне тоже нравится), но не идеально.

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

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

То что тебе нужно называется Имперсонализация, этого в 1С нет, ни в родных процессах доступа к ресурсам, ни во внешних источниках.

+ и да, это понятие есть только под Windows, так что вряд ли 1С поспешат это реализовывать, хотя несомненно это вполне реализуемо и может быть востребовано. )

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

Именно это и было сделано. Кстати походу с доменной аутентификацией походу вообще плохо во внешних источниках. Пробовали вообще под одним пользователем: 1) Вход в домен Windows 2) Вход в базу под тем же пользователем 3) Сервер так же под ним же поднят. В итоге не работает.