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

Введение

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

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

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

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

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

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

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

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

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

Тут есть много способов, начиная от присоединения к серверу посредством SQL Server Management Studio и использования графической оснастки для добавления нужных прав и кончая использованием osql. Мы пойдем вторым путем. Запускаем cmd.exe под пользователем из группы локальных администаторов и выполняем сдедующую команду:
osql -E -S .InstanceName -Q "EXEC sp_addsrvrolemember 'DOMUser', 'sysadmin'", где InstanceName — имя инстанса, а DOMUser — это доменпользователь, которому дается административный доступ к инстансу. В моем случае (с инстансом по умолчанию и для админского пользователя RUventicello) выглядит это так:

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

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

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

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

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

Хоть процедура и не архисложная и никоим образом не каждодневная, она, если честно, немного занудная и утомительная. Одно количество скриншотов является тому подтверждением. Я же являюсь убежденным апологетом утверждения, что все, что занудно, должно делаться компьютером, а не человеком — на то их и создавали. Поэтому я взял и описал все эти шаги в виде скрипта, предлагаемого вашему вниманию. Чтобы воспользоваться скриптом, его надо запустить из-под пользователя с административными привилегиями на машине с инстансом следующим образом:
cscript /nologo acquire_admin_rights.js [<instance-name>], где опциональный параметр instance-name обозначает инстанс, к которому надо предоставить админские права для запускающего пользователя. Если пропустить инстанс или задать имя MSSQLSERVER, доступ будет предоставлен к инстансу по умолчанию. Еще раз напоминаю, что надо удостовериться, что в течение процедуры нет никаких приложений, активно соединяющихся с этим инстансом, так как они могут перехватить единственное соединение, предоставляемое однопользовательским режимом.
В процессе работы скрипт честно рассказывает о своих деяниях, поэтому, если что-то пойдет не так, можно понять, в чем причина и в каком состоянии оставлена система:

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

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

WMI

Вкратце, в контексте нашего повествования, WMI (Windows Management Instrumentation) — это сервис Windows, предоставляющий доступ к конфигурационной информации в унифицированном виде именованных классов, представленных набором свойств. Классы распиханы по пространствам имен (самое популярные из которых — это rootcimv2, в котором живет большинство классов, описывающих систему, и rootdefault, в котором живет класс реестра). На основании класса может существовать один или более экземпляров, обозначающих реальные описываемые объекты. Например, класс Win32_Service — это понятие службы, а каждый экземпляр — это набор свойств, соответствующий реальным службам, установленным на системе.

Microsoft SQL Server в WMI

Тут, как почти всегда с Microsoft, не обошлось от курчавости. Хоть сами SQL сервера обеспечивают обратную совместимость, что-то у них там не срослось на уровне конфигурации, так что абсолютно аналогичные классы конфигурации живут в двух разных пространствах имен:

• rootMicrosoftSqlServerComputerManagement — для SQL Server 2005
• rootMicrosoftSqlServerComputerManagement10 — для SQL Server 2008

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

wbemtest

wbemtest.exe — это стандартный клиент WMI (настолько стандартный, что присутствует в путях), поставляемый c WMI с первых дней появления этого сервиса аж в Windows 2000. Как следствие, интерфейс у этой утилиты суров, что, однако, не приумаляет его мощь. Выглядит он так:

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

Если с 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 мы ищем. Примерно таким же кодом мы присоединяемся к пространству имен rootcimv2, посредством которого работаем со службами. Полученный объект 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, позволившая автоматизировать все действия в виде небольшого скрипта. Перекуем мануалы на скрипты!

Автор: omnisens

Источник