Доброго времени суток!
Требуется сделать странное. Есть сервер MS SQL 2008 R2, к нему прилинкованы пара серверов (доступ по логину и паролю). Хотелось бы чтобы в коде процедуры была возможность запускать процы с линкедсервера с правами данного логина, а под правами например SA писать какието инсерты, просматривать структуру базы и т.д. было бы невозможно?

denis_viktorovich,

Только написал вопрос и понял, что сопоставление имен наверное то, что надо.

Владислав Колосовdenis_viktorovich,

второй линк создайте с логином, имеющим нужные права.

Честно говоря не понял мысли. У меня и так оба линка с логином имеющим нужные права. Смысл в том, что этот сервер будет территориально в другом месте, админить его будут другие люди. Хотелось бы подстраховаться от шалостей скучающего админа например.

denis_viktorovich,

я пока думаю в настройках линка поставить сопоставление учетной под которой программа выполняет нужные действия нужному логину, а остальным "Соединение не устанавливать". Другое дело, что как я понимаю, с нормальными правами на сервере всегда можно в это сопоставление подставить свой логин.

GerrosЕсли вы не хотите чтобы "другие люди" что-то могли поломать на двух прилинкованных серверах, не давайте им паролей SA этих серверов.
Использовать виндовую аутентификацию возможности нет?
Ваша программа требует прав SA для работы?

Паролей СА никто не дает конечно, есть только логин и пароль который имеет все необходимые права,
виндовую не получится, т.к. прилинкованные серверы - не MS SQL,
прав SA она не требует.

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

vikkivdenis_viktorovich...то можно вместо этой учетной подставить другую и обойти эту мою хитрость...Чтобы поставить другую - нужно её знать,
мораль:
1) не раздавать кому попало учётные записи с паролями
2) наделять эти учётные записи соответствующими правами (ограниченно только тем что им можно делать)
3) если уж так необходимо - вести аудит кто и что делал на внешней стороне (не MSSQL)
ну и в первую очередь - не надо раздавать кому-попало/всем подряд права админа (и sa) на MSSQL
Остальное (хоть на каждого пользователя) прописывается соответствующими ограничениями здесь
(можно остальным дать минимальный guest в последнем пункте):



Так я и сделал ровно как на картинке, смущает то, что если есть адм. права на серваке, можно вместо my_write_user написать другой логин и это ведь не запретишь.