Получение административных привилегий в Microsoft SQL Server

Источник: habrahabr

omnisens

Введение

После смены рабочей станции начал ставить на нее Micorosft SQL Server 2008 R2 и чуть было не натолкнулся на традиционные грабли, связанные с улучшенной безопасностью в этой версии.

Если в Microsoft SQL Server 2005 группа локальных администраторов по умолчанию включалась в роль sysadmin на SQL сервере, то в 2008-й в эту роль не включается никто:

В итоге, в инсталляции по умолчанию получается ситуация, в которой к инстансу не имеет административного доступа никто, то есть сделать с этим инстансом нельзя ничего кроме как периодически перезагружать его. Также такая ситуация возникает, когда тот, кто устанавливал SQL сервер, назначив себя единственным администратором, увольняется - например такая ситуация возникла нашими админами.
Данный пост показывает решение этой проблемы и предоставляет автоматизированное решение этой проблемы в виде скрипта, ровно как и рассказывает историю его написания, иллюстрируя мощь WMI, которая недопустимо замалчивается в литературе и в интернете.

Описание процедуры

В решении нет ничего неожиданного или революционного:

Перезагрузить инстанс в однопользовательский режим (single user mode)
Добавить нужного пользователя в администраторы сервера из-под любого пользователя из группы локальных администраторов
Перезагрузить инстанс в нормальный режим

Разжеванное описание процедуры

Перегрузка в однопользовательский режим

Запускаем оснастку конфигурации SQL сервером и останавливаем нужный инстанс (в моем случае - инстанс по умолчанию):
Открываем свойства инстанса:
Переключаемся на вкладку Advanced и прокручиваем свойства к параметру Startup Parameters:
Добавляем параметр -m; (не забываем точку с запятой!). Этот параметр обозначает загрузку инстанса в однопользовательском режиме (single user mode).
В этом режиме любой член группы локальных администраторов имеет привилегии системного администратора на инстансе.
Также в этом режиме возможно единственное соединение с сервером, поэтому любые приложения, которые могут хотеть присоединиться к конфигурируемому инстансу, должны быть погашены.
Полное описание параметров движка базы можно найти тут:
Запускаем инстанс:

Установка админских привилегий для пользователя

Тут есть много способов, начиная от присоединения к серверу посредством SQL Server Management Studio и использования графической оснастки для добавления нужных прав и кончая использованием osql. Мы пойдем вторым путем.

Запускаем cmd.exe под пользователем из группы локальных администаторов и выполняем сдедующую команду:

osql -E -S .\InstanceName -Q "EXEC sp_addsrvrolemember 'DOM\User', 'sysadmin'"

, где InstanceName - имя инстанса, а DOM\User - это домен\пользователь, которому дается административный доступ к инстансу.

В моем случае (с инстансом по умолчанию и для админского пользователя RU\venticello) выглядит это так:

Запуск инстанса в обычном режиме

Идем в обратном порядке:

Останавливаем инстанс
Удаляем параметр -m;
Запускаем инстанс

Вот, собственно и все!

Автоматизация

Хоть процедура и не архисложная и никоим образом не каждодневная, она, если честно, немного занудная и утомительная. Одно количество скриншотов является тому подтверждением. Я же являюсь убежденным апологетом утверждения, что все, что занудно, должно делаться компьютером, а не человеком - на то их и создавали. Поэтому я взял и описал все эти шаги в виде скрипта, предлагаемого вашему вниманию. Чтобы воспользоваться скриптом, его надо запустить из-под пользователя с административными привилегиями на машине с инстансом следующим образом:

cscript /nologo acquire_admin_rights.js [<instance-name>]

, где опциональный параметр instance-name обозначает инстанс, к которому надо предоставить админские права для запускающего пользователя. Если пропустить инстанс или задать имя MSSQLSERVER, доступ будет предоставлен к инстансу по умолчанию. Еще раз напоминаю, что надо удостовериться, что в течение процедуры нет никаких приложений, активно соединяющихся с этим инстансом, так как они могут перехватить единственное соединение, предоставляемое однопользовательским режимом.
В процессе работы скрипт честно рассказывает о своих деяниях, поэтому, если что-то пойдет не так, можно понять, в чем причина и в каком состоянии оставлена система:

Детали по скрипту

Когда я начал писать скрипт, у меня уже был некоторый опыт работы с конфигурацией SQL Server через WMI,

но именно с параметрам командной строки запуска инстанса работать не приходилось.

Именно в этом ключе я и поведу рассказ: что я знал, и как искал то, что мне нужно.

WMI

Вкратце, в контексте нашего повествования, WMI (Windows Management Instrumentation) -

это сервис Windows, предоставляющий доступ к конфигурационной информации в унифицированном виде именованных классов, представленных набором свойств.

Классы распиханы по пространствам имен (самое популярные из которых - это root\cimv2, в котором живет большинство классов, описывающих систему, и root\default, в котором живет класс реестра).

На основании класса может существовать один или более экземпляров, обозначающих реальные описываемые объекты. Например, класс Win32_Service - это понятие службы, а каждый экземпляр - это набор свойств, соответствующий реальным службам, установленным на системе.

Microsoft SQL Server в WMI

Тут, как почти всегда с Microsoft, не обошлось от курчавости.

Хоть сами SQL сервера обеспечивают обратную совместимость, что-то у них там не срослось на уровне конфигурации,

так что абсолютно аналогичные классы конфигурации живут в двух разных пространствах имен:

root\Microsoft\SqlServer\ComputerManagement - для SQL Server 2005
root\Microsoft\SqlServer\ComputerManagement10 - для SQL Server 2008

Соответственно, в общем случае искать наш инстанс надо в двух пространствах имен - ну а вдруг нашим скриптом захотят отконфигурировать пятый сервер?
Итак, мы знаем пространство имен нужных классов, но как они называются, и как с ними работать?

Тут нам на выручку приходит одна довольно корявая, но мощная утилитка - wbemtest.

wbemtest

wbemtest.exe - это стандартный клиент WMI (настолько стандартный, что присутствует в путях),

поставляемый c WMI с первых дней появления этого сервиса аж в Windows 2000.

Как следствие, интерфейс у этой утилиты суров, что, однако, не приумаляет его мощь. Выглядит он так:

Пока мы не присоединимся к нужному пространству имен, делать нам в этой утилитке особо нечего.

К счастью, мы знаем нужное пространство имен:

root\Microsoft\SqlServer\ComputerManagement10

:

Если с WMI все нормально (а у этого сервиса есть тенденция изредка отваливаться), то соединение будет успешным, приглашая нас к взаимодействию активными кнопками:

Ну все, теперь мы готовы копаться в пространстве имен в поисках нужных классов и свойств.

Поиск нужных свойств

Сначала смотрим, какие классы вообще существуют в этом пространстве имен.

Для этого, очевидно, жмем на кнопку Enum Classes и в появившемся не совсем понятном диаложке нажимаем OK. В итоге появляется следующее окно:
.
Обычная женская интуиция подсказываем нам, что это, скорее всего, класс SqlServiceAdvancedProperty.

Даблкликаем, открывая следующий диалог, показывающий свойства данного класса:

Похоже на правду. Посмотрим на экземпляры этого класса и посмотрим, есть ли там интересующие нас параметры.

Для этого нажимаем кнопку Instances и получаем сие окно:

Находим объект

SqlServiceAdvancedProperty.PropertyIndex=13,SqlServiceType=1,PropertyName='STARTUPPARAMETERS',ServiceName='MSSQLSERVER'.

Вот оно счастье!

Работа с WMI из скрипта

Зная, какие классы и свойства нам нужны, остается только получить к ним доступ из скрипта.

Рассматривать будем JScript, потому что распространяется со всеми Windows, да еще и JavaScript. Работа на VBScript или PowerShell ведется аналогично.

Работа с WMI в скрипте начинается как и в случае wbemtest с подключения к нужному пространству имен.

Делается это следующим кодом:

function LookupInstanceContext(instance, scope) { try { var wmi = GetObject("WINMGMTS:\\\\.\\root\\Microsoft\\SqlServer\\" + scope); var settings =

new Enumerator(wmi.ExecQuery("SELECT * FROM ServerSettings WHERE InstanceName='" + instance + "'"));

if (!settings.atEnd()) { return wmi; } } catch (exception) {} return null; }

В качестве

scope

подается либо "ComputerManagement" либо "ComputerManagement10", в зависимости от того, какой версии SQL Server мы ищем.

Примерно таким же кодом мы присоединяемся к пространству имен root\cimv2, посредством которого работаем со службами. Полученный объект wmi реализует интерфейс IWbemServices, но нас интересуют три следующих метода:

ExecQuery

- выполнить запрос на языке WQL и вернуть список результатов

Get

- получить конкретный экземпляр класса по идентификатору

ExecMethod

- вызвать метод на объекте

Чтобы потренироваться в умении делать WQL запросы и смотреть на результаты, нам поможет наш старый друг wbemtest нажатием кнопки Query... на основном окне. Вкратце, WQL (WMI Query Language) - это подмножество SQL в котором в качестве таблицы используется имя класса и выбирать конкретные колонки нельзя - только

SELECT *

. Например, чтобы найти все экземпляры инстанса сервера с именем MSSQLSERVER, можно написать следующий WQL запрос:

Результат представлен в том же виде, в котором нам возвратились экземпляры класса (это и был результат запроса

SELECT * FROM SqlServiceAdvancedProperty

).
Для получения одного объекта по первичного ключу или полному набору свойств (для классов, у которых нет первичных ключей), используется метод

Get

. Вот функция, которая ответственна за получение строкового значения объекта

SqlServiceAdvancedProperty

по заданному пути:

function GetPropertyValue(wmi, path) { return wmi.Get(path).PropertyStrValue; }

Изменение значения свойства подразумевает вызов метода

SetStringValue

(который указан в описании класса

SqlServiceAdvancedProperty

). Чтобы его вызвать надо предварительно создать его аргумент, в который установить требуемое значение. Делается это следующей пачкой вызовов:

function SetPropertyValue(wmi, path, value) { var arg = wmi.Get(path).Methods_("SetStringValue").inParameters.SpawnInstance_(); arg.Properties_.Item("StrValue") =

value; var result = wmi.ExecMethod(path, "SetStringValue", arg); if (result.ReturnValue !=

0) { throw new Error("Failed to set property '" + path + "' to value '" + value + "'"); } }

Заключение

В остальном скрипт самодокументирующийся. Все действия записаны в функции с четкими названиями, пригодные для повторного использования в собственных скриптах.

Используйте на здоровье!
В данном посте была рассмотрена процедура восстановления административных привилегий на SQL Server, а также проиллюстрирована мощь скриптования средствами WMI, позволившая автоматизировать все действия в виде небольшого скрипта. Перекуем мануалы на скрипты!

Ссылки по теме