Testor1
Дата: 27.01.2013 16:53:15
Всем привет!
Столкнулся со следующей проблемой. Написал CLR библиотеку, которая подключается к веб сервису по HTTPS и запрашивает данные.
Все работает корректно из VS 2010 под моей учеткой. Если вызывать процедуру из MSSQL под локальной учёткой (Local, Network, System) то срабатывает исключение с текстом ошибки.
Msg 6522, Level 16, State 1, Procedure sp_CLR_SAPI_proxyLogin, Line 0
A .NET Framework error occurred during execution of user-defined routine or aggregate "sp_procedure1":
System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
System.Security.Authentication.AuthenticationException:
Если сервис MSSQL запустить под своей учеткой, то все работает корректно.
Пробовал запустить сервис запустить под (Local, Network, System) и вызвать процедуру как execute as user. Результат отрицательный.
Сервер находиться в локальной доменной сети. Думал, что проблема в прокси ..., хотя для локальный Ip никаких ограничений не должно быть.
Вопрос.
Как модифицировать скл процедуру или вызываемый код, чтобы все работали с MSSQL сервисом запущенным под одной из учеток (Local, Network, System)? Не хочется создавать технологическую учетную запись и из под нее запускать MSSQL.
Jovanny
Дата: 28.01.2013 11:34:03
Т.е. при запуске сервиса под (Local, Network, System) и процедуры с опцией WITH EXECUTE AS '<учётка с правами доступа к внешним ресурсам>' не работает?
alexeyvg
Дата: 28.01.2013 12:13:05
| Testor1 |
|---|
| Пробовал запустить сервис запустить под (Local, Network, System) и вызвать процедуру как execute as user. Результат отрицательный. |
| BOL, EXECUTE AS |
|---|
| Пользователь user_name должен присутствовать в текущей базе данных и не должен относиться к учетной записи группы. В качестве аргумента user_name нельзя указывать роль, сертификат, ключ или встроенную учетную запись (например, NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService или NT AUTHORITY\LocalSystem). |
Как я понимаю, меняются пользователи для работы с сиквелом, а не внешний пользователь, когда CLR лезет наружу.
Наверное, эту проблему можно решить изменением кода CLR (смотреть, как там в .NET переключается контекст Windows)