- сопоставить имена пользователей локального сервера MS SQL Server с именами пользователей удаленного сервера;
- указать, как связанный сервер должен обрабатывать подключение пользователей, имена которых не сопоставлены.
Для примера создадим связанный сервер "test", который будет связан с базой данных Oracle прописанной в tnsnames.ora как "XYZ", и сопоставим для него пользователя MS SQL Server "mssql_login" с пользователем Oracle "ora_user":
exec master.dbo.sp_addlinkedserver @server = N'test', @srvproduct=N'Oracle', @provider=N'OraOLEDB.Oracle', @datasrc=N'XYZ' go exec master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'test',@useself=N'False',@locallogin='mssql_login',@rmtuser=N'ora_user',@rmtpassword=N'ora_user_password' goРезультат работы скрипта можно увидеть в SQL Server Management Studio. В свойствах связанного сервера нас интересует закладка "Security" ("Безопасность"). В верхней части диалога мы видим таблицу со списком сопоставленных имен, а в нижней способ идентификации пользователей, имена которых не сопоставлены. По умолчанию он имеет значение "Be made using the login's current security context" ("Подключаться с использованием текущего контекста безопасности имени входа"). С этим способом идентификация не сопоставленных пользователей при подключении к удаленной базе данных зависит от способа их подключения к локальному серверу:
- если оно установлено с использованием проверки подлинности SQL Server, то для подключения к удаленному серверу будут использоваться имя и пароль подключившегося пользователя (поэтому на удаленном сервере должны существовать учетные данные пользователя с тем же именем и паролем);
- если оно установлено с использованием проверки подлинности Windows, то для подключения к удаленному серверу будут использоваться учетные данные Windows (учетные данные домена).
exec master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'test',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
Второй вариант "Be made using this security context" ("Подключаться с использованием данного контекста безопасности") – не сопоставленные пользователи локального сервера подключаются к удаленной базе данных под одной учетной записью пользователя удаленного сервера.
exec master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'test',@useself=N'False',@locallogin=NULL,@rmtuser=N'ora_user',@rmtpassword=N'ora_user_password'
Третий вариант "Be made without using a security context" ("Подключаться без использования контекста безопасности") – не сопоставленные пользователи локального сервера подключаются к удаленной базе данных без использования контекста безопасности. Какой-то "мутный" вариант. Гость?
exec master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'test',@useself=N'False',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL
Четвертый вариант "Not be made" ("Не подключаться") – запрет на подключение к удаленной базе данных всем не сопоставленным пользователям. Так как генерация скрипта создания для существующего связанного сервера в SQL Server Management Studio не показывает полную реализацию этого варианта, то над ней пришлось некоторое время подумать. Решение подсказал параметр @locallogin=NULL, который мы указывали в первых трех вариантах. Оказывается, что при вызове sp_addlinkedserver создается сопоставление для локального пользователя с именем равным NULL, которое потом используется для управления подключением не сопоставленных пользователей. Значит, что для переключения на "Not be made" необходимо просто удалить созданное по умолчанию сопоставление. Для этого воспользуемся процедурой sp_droplinkedsrvlogin:
exec master.dbo.sp_droplinkedsrvlogin @rmtsrvname=N'test', @locallogin=NULL
Вот такое "костыльное" решение от Microsoft для настройки подключения к связанному серверу пользователями с не сопоставленными именами. На месте разработчиков этого функционала, я бы скрыл работу с пользователем по умолчанию добавив еще одну процедуру с двумя параметрами (сервер и вариант подключения):
exec master.dbo.sp_defaultlinkedsrvlogin @rmtsrvname=N'test', @connect=XИли это синтаксический сахар?
Комментариев нет:
Отправить комментарий