Ms sql создание пользователя. 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. Также имя входа нельзя удалить, если в данный момент пользователь подключен к системе. Удалить имя входа без удаления сопоставленного пользователя базы данных можно, но это приведет к появлению пользователей, утративших связь с учетными записями.
На этом у меня все надеюсь, материал был Вам полезен, пока!
- 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 [
В процессе работы скрипт честно рассказывает о своих деяниях, поэтому, если что-то пойдет не так, можно понять, в чем причина и в каком состоянии оставлена система:
Детали по скрипту
Когда я начал писать скрипт, у меня уже был некоторый опыт работы с конфигурацией 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 - вызвать метод на объекте
Результат представлен в том же виде, в котором нам возвратились экземпляры класса (это и был результат запроса 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 + """); } }
Набор действий аналогичен).
1. Добавление нового пользователя
Запускаем утилиту . В Microsoft Windows server 2012 R2 ее можно найти в списке всех программ.
В Microsoft Windows Server 2008 R2 в меню «Пуск » (Start) — «Microsoft SQL Server 2012 » — «Среда SQL Server Management Studio ».
В обозревателе объектов раскрываем вкладку «Безопасность » (Security), кликаем правой кнопкой мыши по вкладке «Имена входа » (Logins) и в контекстном меню выбираем «Создать имя входа… » (New Login…)
Откроется окно создания имени входа (Login — New). Теперь необходимо определиться с вариантом аутентификации нового пользователя. Возможны 2 варианта:
- Аутентификация с помощью пароля — Проверка подлинности SQL Server (SQL Server Authentication).
- Доступ для конкретного пользователя Windows — Проверка подлинности Windows (Windows authentication).
2. Проверка подлинности SQL Server
Для начала рассмотрим первый способ аутентификации. Например, создадим пользователя для . Укажем имя входа (Login name), выберем «Проверка подлинности SQL Server » (SQL Server Authentication) и введем пароль (Password) пользователя. Далее снимаем / отмечаем галочки у следующих параметров:
- Требовать использование политики паролей (Enforce password policy)
- Задать срок окончания действия пароля (Enforce password expiration)
- Пользователь должен сменить пароль при следующем входе (User must change password at next login)
Для данной задачи оставляем включенным только первый параметр.
Также сразу рекомендую выбрать язык по умолчанию. Если вы используете английскую версию SQL Server, то и служебные сообщения, которые SQL Server будет передавать приложению, подключенному под данным пользователем (в данном случае программе 1С:Предприятие , следовательно и конечному пользователю, работающему в программе) будут передаваться на английском языке. Если язык по умолчанию для пользователя выбрать, например, русский, то и служебные сообщения будут передаваться на русском языке.
Устанавливаем необходимые параметры и переходим на вкладку «Роли сервера » (Server Roles).
Здесь выбираем набор прав добавляемого пользователя. Для этого отмечаем необходимые роли сервера. С полным описанием предопределенных ролей сервера и их возможностями можно ознакомиться . Для текущей задачи выбираем:
- dbcreator
- processadmin
- public
После чего нажимаем «ОК » для сохранения выполненных действий.
3. Проверка подлинности Windows
Теперь добавим администратора SQL Server, выбрав его из текущих пользователей Windows. Для этого создадим нового пользователя и способ аутентификации укажем «Проверка подлинности Windows » (Windows authentication). Далее, чтобы ввести имя входа, нажмем «Найти » (Search…), затем «Дополнительно » (Advanced…), в следующем окне «Поиск » (Find Now) и выбрав необходимого пользователя из списка, закроем все окна нажав на «ОК ».
Перейдем на вкладку «Роли сервера » (Server Roles) и в соответствии с поставленной задачей укажем роли:
- public
- sysadmin
Нажмем «ОК » для сохранения нового пользователя.
Теперь в списке имен входа среди прочих мы можем увидеть только что созданных пользователей.
Помогла ли Вам данная статья?
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
Вы также можете использовать:
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. Это оно! Теперь вы можете войти в систему, используя свой сетевой логин.
При развертывании информационных баз предприятий на основе решений 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.
