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