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

  • Tutorial

Введение

После смены рабочей станции начал ставить на нее 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 'DOM\User', 'sysadmin'", где InstanceName — имя инстанса, а DOM\User — это домен\пользователь, которому дается административный доступ к инстансу. В моем случае (с инстансом по умолчанию и для админского пользователя RU\venticello) выглядит это так:


Запуск инстанса в обычном режиме
Идем в обратном порядке:
  1. Останавливаем инстанс
  2. Удаляем параметр -m;
  3. Запускаем инстанс
Вот, собственно и все!

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

Хоть процедура и не архисложная и никоим образом не каждодневная, она, если честно, немного занудная и утомительная. Одно количество скриншотов является тому подтверждением. Я же являюсь убежденным апологетом утверждения, что все, что занудно, должно делаться компьютером, а не человеком — на то их и создавали. Поэтому я взял и описал все эти шаги в виде скрипта, предлагаемого вашему вниманию. Чтобы воспользоваться скриптом, его надо запустить из-под пользователя с административными привилегиями на машине с инстансом следующим образом:
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, позволившая автоматизировать все действия в виде небольшого скрипта. Перекуем мануалы на скрипты!
Поделиться публикацией

Комментарии 11

    0
    Ну как говориться… «Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба можно превратить в троллейбус… но зачем?»
    Те вариант с командной строкой гораздо проще.
      +1
      Строго говоря, «варианта с командной строкой» вообще не было. Скрипт останавливает сервис, переводит его в однопользовательский режим, запускает сервис, добавляет текущего юзера в админы, останавливает сервис, восстанавливает многопользовательский режим и перезапускает сервис. В описании ручного добавления только добавление юзера в админы было проведено из командной строки.
      +1
      Пара замечаний:

      На powershell скрипт будет выглядеть не «аналогично», а раз эдак в 5-10 короче.

      Багрепорт:
      function OpenSqlWmiNamespace(instance) {
        var wmi = LookupInstanceContext(instance, "ComputerManagement10");
        if (wmi != null) {
          return wmi;
        }
        var wmi = LookupInstanceContext(instance, "ComputerManagement10");
        if (wmi != null) {
          return wmi;
        }
      
      
        throw new Error("Instance '" + instance + "' not found.");
      }


      Насколько я понимаю, скрипт оба раза пытается работать с одной и той же версией неймспейса. Кроме того, в mssql 2012 имя неймспейса ComputerManagement11. В принципе можно просто перечислить все объекты класса __NAMESPACE в неймспейсе \\root\Microsoft\SqlServer и выбрать подходящий ComputerManagement*
        +1
        Отличная идея, и как я не додумался! Щас переделаю и залью на github. Как говорится, дубликация — источник багов. Что же касается PowerShell, согласен, что на нем лаконичнее, но, к сожалению, его нет на 2003-м сервере по умолчанию, а такие зверушки все еще водятся в нашем зоопарке.
          +1
          Стало так:
          function EnumerateSqlNamespaces() {
            var wmi = GetObject("WINMGMTS:\\\\.\\root\\Microsoft\\SqlServer");
            return new Enumerator(wmi.ExecQuery("SELECT * FROM __NAMESPACE WHERE Name LIKE 'ComputerManagement%'"));
          }
          
          function OpenSqlWmiNamespace(instance) {
            var namespaces = EnumerateSqlNamespaces();
            for (; !namespaces.atEnd(); namespaces.moveNext()) {
              var namespace = namespaces.item();
              var wmi = LookupInstanceContext(instance, namespace.Name);
              if (wmi != null) {
                return wmi;
              }
            }
          
            throw new Error("Instance '" + instance + "' not found.");
          }
          
          0
          [offtopic]
          Скажите спасибо что не batch. Помню видел, как его использовали в не самом легаси проекте, на 2008 сервере… И в универе, помнится, для автоматизации процессов на винде предлагался именно он.
          [/offtopic]
          0
          Е-мае, как страшно жить…

          Чем вам не нравится такой вариант?

          net stop MSSQLSERVER
          net start MSSQLSERVER /m
          osql -E -S .\InstanceName -Q "EXEC sp_addsrvrolemember 'DOM\User', 'sysadmin'"
          net stop MSSQLSERVER
          net start MSSQLSERVER
          


          мануалов на эту тему — куча, вырезал из этого: kaktusenok.blogspot.ru/2011/09/microsoft-sql-server-2008-2005.html
            0
            Мда, ваш вариант настолько прост, что даже как-то хочется от стыда статью удалить. Я не знал, что можно инкрементально сервису параметры доставлять через net start — спасибо!
            Хотя, суть статьи — это иллюстрация работы с WMI из скриптов на конкретном примере. Есть примеры, когда командной строки недостаточно. Например, TCP протокол вроде через командную строку не включишь. Собственно, именно этот свой скрипт я и переделал для этой статьи.
              0
              Иллюстрация удалась, так что статья, конечно, полезная.
              А использование сложных, но знакомых механизмов вместо простых, но незнакомых достаточно часто случается — объем знаний у каждого разный, и мы все идем по пути наименьшего сопротивления.
                0
                Не надо статью удалять. Описание wbemtest имеет самостоятельную ценность, безотносительно к MS SQL Server
                  0
                  ну собственно это то о чем я и говорил…

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

              Самое читаемое