Sql server создание пользователя. SQL Server: Пользовательские роли

Жаропонижающие средства для детей назначаются педиатром. Но бывают ситуации неотложной помощи при лихорадке, когда ребенку нужно дать лекарство немедленно. Тогда родители берут на себя ответственность и применяют жаропонижающие препараты. Что разрешено давать детям грудного возраста? Чем можно сбить температуру у детей постарше? Какие лекарства самые безопасные?

В этой небольшой статье мы разберём SQL-запрос , который позволяет добавлять новых пользователей к базе данных , а также изменять параметры уже существующих.

Давайте приведу сразу пример SQL-запроса на создание нового пользователя базы данных :

GRANT SELECT , INSERT , UPDATE , CREATE , PROCESS ON * . * TO "MyUser"@"localhost" IDENTIFIED BY "123456" WITH GRANT OPTION MAX_QUERIES_PER_HOUR 10 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 10

Теперь давайте разберём SQL-запрос на изменение существующих пользователей :

GRANT SELECT , INSERT , UPDATE , CREATE , PROCESS ON * . * TO "MyUser"@"test1.ru" IDENTIFIED BY PASSWORD "565491d704013245" WITH GRANT OPTION MAX_QUERIES_PER_HOUR 10 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 10

Как видите, синтаксис АБСОЛЮТНО такой же, как и на создание нового пользователя. Единственное отличие - это то, что пользователь "MyUser " уже существует. Вот и всё.

И, наконец, удаление пользователя из базы данных . Тут есть один интересный момент. Дело в том, что данные пользователей базы данных сами хранятся в таблицах базы данных. Поэтому, чтобы удалить пользователя надо удалить записи в соответствующих таблицах. Вот код:

DELETE FROM `user` WHERE CONVERT(User USING cp1251) = CONVERT("MyUser" USING cp1251) AND CONVERT(Host USING cp1251) = CONVERT("test1.ru" USING cp1251)
DELETE FROM `db` WHERE CONVERT(User USING cp1251) = CONVERT("MyUser" USING cp1251) AND CONVERT(Host USING cp1251) = CONVERT("test1.ru" USING cp1251)
DELETE FROM `tables_priv` WHERE CONVERT(User USING cp1251) = CONVERT("MyUser" USING cp1251) AND CONVERT(Host USING cp1251) = CONVERT("test1.ru" USING cp1251)
DELETE FROM `columns_priv` WHERE CONVERT(User USING cp1251) = CONVERT("MyUser" USING cp1251) AND CONVERT(Host USING cp1251) = CONVERT("test1.ru" USING cp1251)

Много, не спорю, но это единственный способ удалить пользователя. Либо вручную через PHPMyAdmin . Единственное, что надо изменить в этом шаблоне - это имя пользователя и хост, а всё остальное Вам вряд ли придётся менять.

Tutorial

Введение

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

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

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

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

Перезагрузить инстанс в однопользовательский режим (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 обозначает инстанс, к которому надо предоставить админские права для запускающего пользователя. Если пропустить инстанс или задать имя 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 2000, - роль bulkadmin появилась в SQL Server 2005). Теперь, с появлением SQL Server 2012 наконец появилась возможность создания нестандартных, или пользовательских, ролей сервера.

Многие годы недоступность такой функциональности была источником головной боли администраторов SQL Server. Что вы делали, если нужно было предоставить права нескольким пользователям или группам на уровне экземпляра и обеспечить синхронизацию этих прав? Допустим, вам нужно предоставить право View System State большому числу пользователей, чтобы они могли видеть информацию о блокировке в центрах разработки. Приходилось предоставлять права по отдельности каждому пользователю или доменной группе.

Если все имена входа являлись доменными, был обходной путь: можно было создать доменную группу, в которую включить всех пользователей, кому были нужны такие права (при этом надо было создавать отдельные группы для каждого сервера, если нужно было предоставить права на нескольких серверах). Можно было добавить пользователей в эту группу, создать имя входа, связанное с этой доменной группой, после чего предоставить группе право View Server State на сервере. Но это нужно было делать очень внимательно. Иначе можно было предоставить право входа пользователям, у которых такого права раньше не было. Существовала даже возможность предоставления пользователям прав, которых им предоставлять нельзя.

Создание роли средствами T/SQL

Существует много способов создания пользовательской роли на сервере, в том числе средствами T/SQL, SQL Server Management Studio и Windows PowerShell. Если нужно создать пользовательскую серверную роль с применением T/SQL, нужно воспользоваться тремя командами: инструкция Create Server Role создаст пользовательскую серверную роль, инструкция Alter Server Role добавит пользователя в роль и, наконец, инструкция Grant предоставит нужные права роли.

Использование этих трех инструкций показано в следующем коде, который создает пользовательскую серверную роль по имени ViewServerState. В роль добавляется пользователь SomeFakeLogin, и роли предоставляется право View Server State. Чтобы предоставить это право другим пользователям, достаточно просто добавить их в готовую роль инструкцией Alter Server Role.

USE GO CREATE SERVER ROLE AUTHORIZATION GO ALTER SERVER ROLE ADD MEMBER GO GRANT VIEW SERVER STATE TO GO

Для удаления пользователя из роли используется инструкция Alter Server Role. При этом используется на параметр Add Member, а Drop Member:

ALTER SERVER ROLE DROP MEMBER GO

Когда нужно развернуть одну или более пользовательских серверных ролей на многих экземплярах SQL Server, есть несколько возможных вариантов. Наверняка вам не понравится подключаться к каждому серверу по отдельности и создавать на них пользовательские серверные роли. Один из вариантов - использование консоли SQL Server Management Studio. В ней можно выполнять сценарии на T/SQL сразу на нескольких экземплярах.

Можно также воспользоваться компонентами Windows PowerShell сервера SQL Server для развертывания новых пользовательских серверных ролей на всех экземплярах SQL Server в организации. (Существует много вариантов использования Windows PowerShell для выполнения задачи, но их описание выходит за рамки этой статьи.)

Консоль SQL Server Management Studio

Задачу можно легко выполнить средствами графического интерфейса SQL Server Management Studio. Чтобы создать пользовательскую серверную роль, подключитесь к экземпляру средствами Object Explorer. В обозревателе объектов перейдите к узлу <имя_экземпляра >/Security/Server Roles. Щелкните правой кнопкой Server Roles и выберите New Server Role. В открывшемся окне New Server Role в поле Server role name укажите имя роли, в поле Owner укажите владельца роли, после чего укажите объекты и разрешения, которые должны предоставляться членам роли (рис. 1 ).

Рис. 1. Укажите права, которые должна предоставлять роль

По завершении работы на странице General перейдите на страницу Members (рис. 2 ) и укажите имена входа SQL Server, которые должны входить в эту пользовательскую серверную роль.

Рис. 2. Определение членов роли

После определения членов роли на странице Members перейдите на страницу Memberships. Здесь задаются серверные роли, членом которых должна быть пользовательская серверная роль. Если на этой странице выбрать какую-то роль, пользователи, члены создаваемой пользовательской серверной роли, будут также обладать правами выбранной роли.

Если создать пользовательскую роль и сделать ее членом фиксированной серверной роли serveradmin (рис. 3 ), все члены вновь созданной пользовательской роли будут также обладать правами роли serveradmin. Как и при вложении доменных групп или ролей баз данных, при вложении ролей надо соблюдать большую осторожность, чтобы не предоставить пользователям прав, которых у них быть не должно.

Рис. 3. Пользовательские роли можно включать в другие серверные роли

Чтобы организовать вложение ролей средствами T/SQL, снова потребуется инструкция Alter Server Role с параметром Add Member. Например, чтобы сделать пользовательскую серверную роль ViewServerState членом фиксированной серверной роли setupadmin, нужно изменить фиксированную серверную роль setupadmin.

ALTER SERVER ROLE ADD MEMBER GO

В пользовательских серверных ролях может быть много пользователей. Есть десятки прав уровня экземпляра, которые можно предоставить пользовательской серверной роли для упрощения управления этими правами. Можно также создать роль для младшего администратора БД, которой предоставить часть, но не все права администратора. Можно создать группу AlwaysOnAdmin, которая предоставляет право на выполнение перехода базы данных AlwaysOn (что должно выполняться в рамках SQL Server) не предоставляя всей полноты административных прав.

Существует масса ситуаций, в которых пользовательские серверные роли оказываются очень кстати. Они значительно облегчат работу администратора. Также такие группы позволят повысить безопасность экземпляров SQL Server за счет снижения вероятности случайного предоставления пользователям прав, которых предоставлять нельзя.

Всем привет! Сейчас мы с Вами рассмотрим примеры создания и удаления пользователей в СУБД Microsoft SQL Server как с использованием инструкций Transact-SQL, так и с использованием среды Management Studio.

Процесс создания пользователей в MS SQL Server включает два этапа:

Создание имени входа на SQL Server. Данное имя необходимо, для того чтобы предоставить пользователю возможность подключиться к экземпляру SQL Server;
Создание пользователя базы данных. В данном случае мы уже предоставляем пользователю разрешения на объекты базы данных.

Примечание! В качестве SQL сервера у меня для примера будет выступать версия Microsoft SQL Server 2012 Express . На данном SQL сервере создана тестовая база данных Test.

Создание имени входа на MS SQL Server

Прежде чем приступать к созданию имени входа на SQL сервер необходимо определиться с методом аутентификации. Существует два варианта:

Проверка подлинности Windows – это когда имя входа может идентифицировать пользователя как учетную запись Windows или как члена группы Windows (в том числе и доменные учетные записи, и группы );
Проверка подлинности SQL Server . В данном случае имя входа существует только в SQL Server.

Давайте рассмотрим пару примеров создания имени входа на SQL сервер. Сначала мы это сделаем с помощью среды SQL Server Management Studio , а затем с использованием языка Transact-SQL.

Создание имени входа с использованием среды SQL Server Management Studio

Запускаем Management Studio, затем в обозревателе объектов находим пункт «Безопасность », раскрываем его плюсиком, кликаем правой кнопкой мыши по пункту «Имена входа » и выбираем пункт «Создать имя входа ».

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

Затем нажимаем на кнопку «ОК », после чего будет создано имя входа TestLogin. По умолчанию данное имя входа будет включено, и оно будет иметь права роли сервера «public».

Создание имени входа с использованием языка Transact-SQL

Для того чтобы создать имя входа на языке Transact-SQL необходимо в Management Studio открыть редактор запросов и выполнить следующую инструкцию (она делает ровно то же самое, что и наши действия выше в графическом интерфейсе Management Studio ).

CREATE LOGIN WITH PASSWORD=N"Pa$$w0rd", DEFAULT_DATABASE=, DEFAULT_LANGUAGE=[русский], CHECK_EXPIRATION=OFF, CHECK_POLICY=ON GO

Другими словами для создания имени входа в SQL сервер используется инструкция CREATE LOGIN .

Создание имени входа на SQL Server с проверкой подлинности Windows

Для того чтобы создать имя входа с проверкой подлинности Windows выполните следующую SQL инструкцию:

CREATE LOGIN FROM WINDOWS WITH DEFAULT_DATABASE=, DEFAULT_LANGUAGE=[русский]; GO

ComputerName\NameUser – это Имя компьютера\Имя пользователя;
FROM WINDOWS – указывает, что будет использоваться проверка подлинности Windows;
WITH DEFAULT_DATABASE= – база данных по умолчанию;
DEFAULT_LANGUAGE=[русский] – язык по умолчанию.

Отключение и включение имен входа в MS SQL Server

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

Отключение ALTER LOGIN TestLogin DISABLE; --Включение ALTER LOGIN TestLogin ENABLE;

Создание пользователя базы данных в MS SQL Server

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

Давайте создадим пользователя TestLogin также двумя способами, т.е. с помощью Management Studio и языка T-SQL .

Создание пользователя базы данных с помощью Management Studio

Открываем Management Studio, в обозревателе объектов находим нужную базу данных и открываем ее плюсиком. Затем также плюсиком открываем пункт «Безопасность » и кликаем по папке «Пользователи » правой кнопкой мыши и выбираем пункт «Создать пользователя ».

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

Также давайте сразу отметим роль базы данных, которую будет иметь данный пользователь. На странице «Членство » я поставил галочку напротив роли db_datareader , т.е. пользователь будет иметь права на чтение данных из пользовательских таблиц. Жмем «ОК ».

Создание пользователя базы данных с помощью языка Transact-SQL

Следующая инструкция T-SQL создает пользователя базы данных (схема по умолчанию dbo ) и назначает ему роль db_datareader, т.е. делает то же самое, что и мы чуть ранее в графическом интерфейсе Management Studio.

USE Test GO CREATE USER FOR LOGIN WITH DEFAULT_SCHEMA= GO ALTER ROLE ADD MEMBER ; GO

Таким образом, инструкция CREATE USER используется для создания пользователя базы данных.

Удаление пользователя базы данных и имени входа в MS SQL Server

Для того чтобы удалить пользователя базы данных можно написать простую SQL инструкцию, например

DROP USER Testlogin;

Или использовать графический инструмент Management Studio, т.е. в обозревателе объектов, в нужной базе данных выбираем «Безопасность -> Пользователи » и щелкаем правой кнопкой мыши по пользователю, которого необходимо удалить, и выбираем «Удалить ».

Примечание! Пользователи, которые владеют защищаемыми объектами, не могут быть удалены из базы данных.

Для удаления имени входа можно также использовать и графический инструмент Management Studio (т.е. «Безопасность -> Имена входа» правой кнопкой мыши по имени, а затем нажать на пункт «Удалить» ) и инструкцию Transact-SQL т.е.

DROP LOGIN TestLogin;

Примечание! Удалить текущее имя входа нельзя, как и имя входа, владеющее любым защищаемым объектом уровня сервера или заданием агента SQL Server. Также имя входа нельзя удалить, если в данный момент пользователь подключен к системе. Удалить имя входа без удаления сопоставленного пользователя базы данных можно, но это приведет к появлению пользователей, утративших связь с учетными записями.

На этом у меня все надеюсь, материал был Вам полезен, пока!