Создание пользователя ms sql. Добавление пользователей базы данных

Десятки лет существовала возможность определения пользовательских ролей в базах данных для облегчения управления процессом предоставления разрешений на доступ к базе данных, но на уровне экземпляра всегда существовало девять фиксированных ролей (или восемь, если вы используете версию, предшествующую 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 за счет снижения вероятности случайного предоставления пользователям прав, которых предоставлять нельзя.

При развертывании информационных баз предприятий на основе решений 1С в клиент-серверном режиме с использованием СУБД MS SQL иногда бывает нужно, чтобы разные базы создавались от имени разных пользователей. Т.е. нам бывает нужно завести в SQL Management Studio пользователя, отличного от sa и ввести его данные в поля окна добавления новой ИБ. (рис1.)

Каковы минимальные права, при которых это всё будет функционировать?

В материалах методической поддержки ИТС говорится, что «этот пользователь должен иметь не только полные права на базу данных информационной базы, но и права на создание баз данных в SQL-сервере и на чтение таблиц базы данных Master». Чтобы посмотреть, как это работает на практике, проведем тестовую установку ИБ в клиент-серверном варианте, используя MS SQL Server 2008 R2 Express. Можно, конечно же, тупо скопировать параметры пользователя sa, но давайте сделаем это осмысленно, это всегда полезно.

Запустим среду SQL Management Studio 2008 R2, установим соединение с SQL-сервером и откроем раздел Безопасность->Имена входа и выберем команду контекстного меню «Создать имя входа», зададим имя пользователя и установим права dbcreator, public (рис.2)

На странице свойств пользователя «Сопоставление пользователей» отметим флажком «Схема» все базы в таблице сопоставленных пользователей master, model, msdb, tempdb, и для каждой базы из таблицы отметим членство в ролях public, db_owner (рис.3)

Теперь можно вернуться к окну, изображенному на рис. 1 и применить введенные параметры. Нажимаем Далее- > Готово и... база создана, список баз увеличился на одну позицию.

Таким образом, мы сможем обрадовать и успокоить системного администратора, ведь указанная комбинация прав пользователя MS SQL минимально достаточна для использования с платформой 1С в клиент-серверном режиме, и пароль «sa» останется не скомпрометированным, а у нас есть нужные нам права пользователя MS SQL.

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 + """); } }

5 ответов

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

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

CREATE LOGIN NewAdminName WITH PASSWORD = "ABCD" GO

Вот как вы создаете пользователя с привилегиями db_owner, используя только что объявленный Логин:

Use YourDatabase; GO IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = N"NewAdminName") BEGIN CREATE USER FOR LOGIN EXEC sp_addrolemember N"db_owner", N"NewAdminName" END; GO

Теперь логины немного более жидкие, чем я, кажется, выше. Например, учетная запись пользователя автоматически создается (в большинстве установок SQL Server) для учетной записи администратора Windows при установке базы данных. В большинстве ситуаций я просто использую это, когда я управляю базой данных (у нее есть все привилегии).

Однако, если вы собираетесь получать доступ к SQL Server из приложения, вам нужно настроить сервер для "Смешанного режима" (как для Windows, так и для SQL-входа) и создать Login, как показано выше. Затем вы получите "GRANT" priviliges для этого SQL-входа на основе того, что необходимо для вашего приложения. См. для получения дополнительной информации.

ОБНОВЛЕНИЕ: Аарон указывает на использование sp_addsrvrolemember для назначения подготовленной роли вашей учетной записи. Это хорошая идея - быстрее и проще, чем предоставление привилегий вручную. Если вы его найдете, вы увидите множество ссылок. Однако вы все равно должны понимать различие между логином и пользователем.

Полные права администратора для всего сервера или конкретной базы данных? Я думаю, что остальные ответили за базу данных, но за сервер:

USE ; GO CREATE LOGIN MyNewAdminUser WITH PASSWORD = N"abcd", CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF; GO EXEC sp_addsrvrolemember @loginame = N"MyNewAdminUser", @rolename = N"sysadmin";

Вам может потребоваться оставить параметры CHECK_ в зависимости от того, какую версию SQL Server Express вы используете (почти всегда полезно включать эту информацию в ваш вопрос).

Если вы хотите создать общий script, вы можете сделать это с помощью инструкции Execute с заменой с вашим именем пользователя и именем базы данных

Declare @userName as varchar(50); Declare @defaultDataBaseName as varchar(50); Declare @LoginCreationScript as varchar(max); Declare @UserCreationScript as varchar(max); Declare @TempUserCreationScript as varchar(max); set @defaultDataBaseName = "data1"; set @userName = "domain\userName"; set @LoginCreationScript ="CREATE LOGIN [{userName}] FROM WINDOWS WITH DEFAULT_DATABASE ={dataBaseName}" set @UserCreationScript =" USE {dataBaseName} CREATE User [{userName}] for LOGIN [{userName}]; EXEC sp_addrolemember ""db_datareader"", ""{userName}""; EXEC sp_addrolemember ""db_datawriter"", ""{userName}""; Grant Execute on Schema:: dbo TO [{userName}];" /*Login creation*/ set @LoginCreationScript=Replace(Replace(@LoginCreationScript, "{userName}", @userName), "{dataBaseName}", @defaultDataBaseName) set @UserCreationScript =Replace(@UserCreationScript, "{userName}", @userName) Execute(@LoginCreationScript) /*User creation and role assignment*/ set @TempUserCreationScript =Replace(@UserCreationScript, "{dataBaseName}", @defaultDataBaseName) Execute(@TempUserCreationScript) set @TempUserCreationScript =Replace(@UserCreationScript, "{dataBaseName}", "db2") Execute(@TempUserCreationScript) set @TempUserCreationScript =Replace(@UserCreationScript, "{dataBaseName}", "db3") Execute(@TempUserCreationScript)

Вы можете использовать:

CREATE LOGIN WITH PASSWORD = "" ; GO

Вы также можете использовать:

GRANT permission [ ,...n ] ON SCHEMA:: schema_name

Чтобы настроить разрешения для схемы, которой вы назначили пользователям.

На прошлой неделе я установил версию Microsoft SQL Server 2014 Developer Edition на свою dev-страницу и сразу же столкнулся с проблемой, которую я никогда раньше не видел.

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

Ошибка входа в SQL Server 18456 "Ошибка входа для пользователя... (Microsoft SQL Server, ошибка: 18456)" Я использовал эту ошибку, если я ввел неверный пароль при входе в систему - но это только если Im использует смешанный режим (Windows и SQL Authentication). В этом случае сервер был настроен только с помощью проверки подлинности Windows, а учетная запись пользователя была моей. Im все еще не уверен почему он не добавлял моего потребителя к роли SYSADMIN во время установки; возможно, я пропустил шаг и забыл добавить его. Во всяком случае, не всякая надежда была потеряна.

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

Остановить службу MSSQL. Откройте командную строку, используя команду "Запуск от имени администратора". Перейдите в папку, в которой хранится EXE файл SQL Server; по умолчанию для SQL Server 2014 используется "C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Binn". Выполните следующую команду: "sqlservr.exe -m". Это запустит SQL Server в однопользовательском режиме. Выйдя из этой командной строки, откройте еще один, повторите шаги 2 и 3. Во втором окне командной строки запустите "SQLCMD -S Server_Name\Instance_Name" В этом окне запустите следующие строки, нажав Enter после каждого из них: 1

СОЗДАТЬ ВХОД [имя_домена\имя_пользователя] ИЗ WINDOWS 2 ИДТИ 3 SP_ADDSRVROLEMEMBER "LOGIN_NAME", "SYSADMIN" 4 ИДТИ Используйте CTRL + C для завершения обоих процессов в окнах командной строки; вам будет предложено нажать Y, чтобы завершить процесс SQL Server.

Перезапустите службу MSSQL. Это оно! Теперь вы можете войти в систему, используя свой сетевой логин.

Создание пользователей баз данных SQL Server 2005, CREATE USER, свойства пользователей

Создать пользователя базы данных можно:

q на графическом экране из контейнера Имя_базы_данных | Security | Users в Management Studio ;

q при помощи команды CREATE USER (хранимая процедура sp _ adduser , которая использовалась для этой цели в предыдущих версиях SQL Server , оставлена только для обеспечения обратной совместимости). Например, команда на создание пользователя User1 , которому будет соответствовать логин SQL Server Login1 со схемой по умолчанию dbo , может выглядеть так:

CREATE USER User1 FOR LOGIN Login1 WITH DEFAULT_SCHEMA = dbo;

При создании пользователя вам нужно будет указать:

q имя пользователя (User name ), к которому применяются те же правила, что и для других объектов SQL Server ;

q логин (SQL Server или Windows ), которой будет назначен пользователю этой базы данных. После создания пользователя назначенный ему логин изменять будет нельзя. Можно создать пользователя, которому не будет назначен никакой логин (при помощи переключателя Without login ). Такому пользователю уже не получится назначить логин. Пользователи этого типа - без логинов - используются только для дополнительной настройки безопасности в Service Broker . Отметим также, что если какой-то логин уже был назначен пользователю, то другому пользователю одновременно назначить его нельзя;

q сертификат (Certificate name ) или асимметричный ключ (Key name );

q схему по умолчанию (Default schema );

q для каких схем этот пользователь будет являться владельцем (Owned schemas );

q какие роли базы данных (Database roles ) будут ему назначены.

Обязательных параметра всего два - имя пользователя и логин.

На вкладке Securables пользователю можно сразу же предоставить разрешения на объекты базы данных. Речь о предоставлении разрешений пойдет в следующих разделах. Вкладка Extended Properties позволяет определить дополнительные пользовательские свойства для данного объекта. Применяются они для тех же целей, что и расширенные свойства баз данных (см. разд. 4.8) .

Изменение свойств пользователя и его удаление производится из того же контейнера в Management Studio , что и создание пользователя, а также при помощи команд ALTER USER/DROP USER . Удалить пользователя, владеющего какими-либо объектами в базе данных, нельзя.

Возможно, будет полезно почитать: