Опция 2. Be made using this security context
Опция вторая, значительно менее востребованная и рекомендуемая, но все же имеющая место быть — «трансформация» локального клиента в указанного клиента на удаленном сервере. Попробуем протестировать эту опцию и сделать так, что бы Фрэнк распознавался как он есть на сервере локальном, а сервер удаленный должен «думать» что к нему подключается Мэри. Очевидно, для подобного «финта», нам требуется логин для Мэри. На локальном сервере он уже есть, создадим такой же на удаленном из admin-студии:
1 2 3 | USE master GO CREATE LOGIN [WINR2\mary] FROM WINDOWS |
Теперь, разумеется, сам связанный сервер нужно переключить в ту опцию безопасности что мы собрались тестировать. Из той же admin-студии открываем свойства linked server по имени WINR2\MSSQL2 и сразу идем на страницу Security. Наша вторая опция — последняя по порядку, ее и выбираем. Становятся доступными поля Remote Login и With password. Это и есть параметры того пользователя, которым Фрэнк будет представляться удаленному серверу, т.е. как последний будет «видеть» первого. Вводим туда WINR2\mary и ее пароль соответственно.
И щелкаем OK. Точнее пытаемся это сделать, ибо нам «вываливается» предупреждение
Хм... Внимательно вчитавшись в документацию (что, кстати говоря, весьма полезно и даже само по себе, без связи с решением конкретных проблем) понимаем нашу ошибку: удаленный пользователь должен иметь имя входа (логин) только с проверкой подлинности SQL Server, а не с интегрированной проверкой силами операционной системы, как у нас. Да, вот так. Ладно, исправим. Жмем в окне с предупреждением No отказываясь пока от дальнейшего редактирования свойств связанного сервера. Никуда не уходя из admin-студии выполняем на удаленной машине:
1 2 3 4 5 6 | USE master GO DROP LOGIN [WINR2\mary] GO CREATE LOGIN mary WITH PASSWORD='123', CHECK_POLICY=OFF GO |
Изменили Windows-логин на почти такой же но из группы SQL-логинов. Теперь — поскольку, и это уже очевидно, мы будем пытаться подключиться к удаленному серверу с SQL-логином, режим аутентификации указанного сервера нужно перевести в mixed-режим. Открываем окно свойств именованного инстанса, закладка Security, опция SQL Server and Windows Authentication mode. OK и не забываем рестартовать сервис движка удаленного сервера!
Что теперь? Снова пробуем изменить опцию безопасности связанного сервера как мы это делали только что. Несмотря на ошибку наш последний выбор (Be made using this security context) все же запомнен, как и параметры удаленного пользователя. Мы должны слегка подправить имя удаленного пользователя (WINR2 с обратным слешем теперь совершенно «не при делах»), заново ввести пароль и щелкнуть OK дабы проверить — «победили» мы предыдущую ошибку? Опыт показывает что да — теперь окно свойств закрывается без малейшего звука. Опция установлена, можно переходить к тестам.
Переключаемся в frank-студию и пробуем исполнить все тот же однострочный скрипт. Видим:
The server principal "mary" is not able to access the database "DB1" under the current security context.
Ага, значит сервер удаленный «думает» что к нему пытается подключиться (хотя почему «пытается»? подключение, как таковое, вполне успешно) не Фрэнк, а Мэри! Ну а саму ошибку-то мы уже «проходили» — пользователь, разрешение... Сейчас из admin-студии все поправим:
1 2 3 4 5 6 | USE DB1 GO CREATE USER mary FOR LOGIN [mary] GO GRANT EXECUTE ON SCHEMA::[dbo] TO [mary] GO |
И снова выполняем тест-скрипт «от Фрэнка»:
mary mary
Что же, все как было обещано: опция Be made using this security context «подменила» пользователя исходного на указанного. Таким образом на локальном сервере проверяются права Фрэнка, на удаленном — Мэри. Самое главное помнить, что «подменный» user может «происходить» только от SQL-логина, ни в коем случае не Windows. Собственно оно и понятно, реализация последнего варианта означала бы что пользователи обретают возможность «подсовывать» серверу чужие маркеры доступа, а это огромнейшая брешь в системе безопасности как таковой. Поэтому — спасибо, не надо, обойдемся одними SQL-логинами.
Наконец, почему эта опция занимает вторую строчку в списке «рекомендовано», а первая досталась опции предыдущей? Причина проста: в прошлом варианте (Опция 1. Be made using the login's current security context) каждый пользователь имел на удаленном сервере свой собственный набор разрешений. Понятно, что можно завести одну удаленную роль, «свалить» туда всех пользователей и набор снова будет один. Но это уж как мы, администраторы, захотим. А чисто технически первая опция позволяет иметь столько наборов разрешений, сколько пользователей у нас в системе. Чего не скажешь о второй опции, протестированной нами в текущем разделе. Вот у нее действительно один список удаленных разрешений для всех локальных пользователей даже с технической точки зрения. В действительно больших и сложных распределенных системах этот вариант крайне сомнителен как финальная опция выбранная для реализации. Но вот в условиях small/home office — почему бы и нет, собственно? Особенно с учетом того, что удаленными могут быть системы данных значительно более простые и куда как менее «навороченные» по сравнинию с SQL Server, вроде тех же Access/Excel.
Опция 3. Be made without using a security context.
Сразу же давайте в admin-студии попробуем сменить настройки безопасности нашего linked server. Мы уже знаем как это делается, а очередная опция будет второй на все той же странице Security. Никаких дополнительных указаний она не требует, просто OK.
Сразу же получаем «отлуп»:
Cannot initialize the data source object of OLE DB provider "SQLNCLI10" for linked server "WINR2\MSSQL2".
OLE DB provider "SQLNCLI10" for linked server "WINR2\MSSQL2" returned message
"Invalid authorization specification". (Microsoft SQL Server, Error: 7399)
Что, собственно, произошло? Произошла очень простая вещь: окно Linked Server Properties попыталось протестировать подключение к удаленному серверу с указанными настройками и у него ничегошеньки не получилось. Ну а чего мы, собственно, ждали, если обсуждаемая опция буквально означает «не передавать никаких сведений о пользователе»? Конечно целевой сервер будет отвергать такое анонимное подключение! Зачем же такая опция нужна? Если удаленный сервер у нас SQL Server или иная СУБД имеющая механизм аутентификации то указанная опция совершенно бесполезна. Можно просто не создавать связанный сервер и результат будет тот же. Но дело в том, что далеко не все data sources имеют такой механизм. Допустим простые текстовые файлы, или файлы Excel — у них, как и у ряда прочих поставщиков данных, аутентификация начисто отсутствует как процесс. Зачем же в этом случае «гонять» лишнюю (и, заметим, весьма ценную информацию) по проводам? Ставим опцию Be made without using a security context и дело с концом!
Возвращаясь к нашей практике. Несмотря на полученное сообщение отвечаем в окне с ошибкой No, подтверждая свое желание перевести настройки безопасности к опции Be made without using a security context. Опция, конечно, сохранилась но в нашем окружении, конкретно для удаленного сервера типа SQL Server, мы получили полностью бесполезное решение. Можем, интереса для, попробовать выполнить наш стандартный тест-скрипт увидев более чем ожидаемое:
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "SQLNCLI10" for linked server "WINR2\MSSQL2" reported an error. Authentication failed.
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "SQLNCLI10" for linked server "WINR2\MSSQL2".
Одним словом — понятно. Опция только для «простейших» провайдеров данных, однако вот для них она просто сущая находка.
И еще один момент связанный с этой опцией нужно иметь в виду. При создании нового linked server через интерфейс студии (ровно как это делали мы с вами), если вообще не заглядывать на страницу Security то именно описываемая опция будет принята как режим подключения к такому удаленному серверу. Иными словами, именно она является «дефолтной» опцией при создании нового связанного сервера. Сделано это умышленно, дабы в большинстве случаев у нас не было иного варианта кроме как все же посетить страницу Security и произвести там осознанный выбор. Однако, повторю, таковой она становится только когда linked server создается через студию. Забавно, но если ровно тоже самое мы будем делать в T-SQL коде (что вполне возможно, просто мы не будем на это отвлекаться) дефолтная опция поменяется и будет уже самая первая из рассмотренных нами, Be made using the login's current security context. Такие вот тонкие и мало ожидаемые различия...
Опция 4. Not be made.
Наконец попробуем выбрать самую первую опцию во все том же окне свойств связанного сервера, опцию Not be made (т.е. не производить подключение).
После щелчка по OK получаем сообщение даже еще более ожидаемое чем в предыдущем случае:
По простому говоря — доступ к удаленному серверу закрыт, ровно как мы и хотели когда выбирали такую опцию. Щелкаем No предписывая все-таки взять и вооружение эту опцию и, скорее для чувства завершенности эксперимента, все-таки выполняем «Фрэнк-тест». Вы не удивитесь:
Access to the remote server is denied because no login-mapping exists.
Интересный вопрос — предыдущая опция и эта вообще чем-то отличаются? Нет, понятно, для всяких простых-текстов-экселей разница чуть более чем кардинальная: в предыдущем варианте мы данные получаем, а в этом нет. А вот для SQL Server и прочих «взрослых» СУБД? Как ни странно разница есть и для них! Ну то есть как: с практической точки зрения разницы ноль, что там данных не получим, что тут (да что там данные, даже соединение в обоих случаях установлено не будет). А вот с точки зрения «большой науки»... В текущем варианте локальный сервер даже не посылает запрос на установку соединения с сервером удаленным. Но в предыдущем случае такой запрос все же отправляется. Да, затея обречена с самого начала — но это не проблемы локального сервера. Ему сказано соединяться с «пустым» пользователем — он и соединяется. Поэтому-то и ошибки в двух случаях разные, как мы с вами видели. Так что ответ на вопрос «есть ли разница» зависит от того что вам ближе — теория или практика.